|
View:
New views
2 Messages
—
Rating Filter:
Alert me
|
|
|
|
|
|
Re: Digest Number 1248> I don't think Force Removal is what I want. There may be legitimate
> reasons for keeping ignored files in a folder... such as there being a > 500mb video file that doesn't belong in SVN, but it needs to be there > for my application to work. I just want SVN to ignore that it is > there. I do NOT want it to delete that folder. I want it to allow for > a local folder to exist that doesn't actually have a conflict with > whatever a branch wants to put there. Different behavior entirely. > Force Removal doesn't sound like it does this. I agree, in this case Force Removal is not desired. I had situations where switching with (Smart)SVN turned unversioned directories to ignored ones and vice versa without complaints. So it would still be important to get your conflicts somehow reproducible (maybe log.txt from within SmartSVN's home directory will help to understand). > Okay. I think it would be the best goal to aim for, though. If a > switch fails, it should tell me why, but it should either 1) continue > trying to switch the rest of the project as I told it to (which it > doesn't), or 2) roll back all the changes it made thus far except for > the conflict, or 3) put all the changes into a change set so I can roll > it back if I want to get back to a pristine copy. Regarding (1) and (2), I think our possibilities are very limited here as this is related to core SVN mechanism. I didn't understand the advantage of (3), especially when you are performing the switch with a clean working copy (i.e. no modified files). > One of the severe problems I ran into was I could not get to ANY valid > version of a branch or trunk because folder conflicts prevented it. I > tried to switch both directions, I tried reverting, and in the end I had > to manually resolve a bunch of stuff that ended up costing me a day > worth of work to figure out. I would really like to get an understanding of these conflicts. Do you expect to perform similar switches in the near future again? If yes, we will whether we can add some more debug information to the connection.log. > OH! And by the way, the terminology in the Resolve menu is horribly > ambiguous and vague. It should not say some fixed string, like pristine > this or before that or pristine the other. It should simply say "Take > [branch xyz]", "Take [trunk]" or "Take merged". I screwed up several > files just trying to understand the language being used in the dialog > box, not really that I didn't know what I wanted to happen. I knew what > files I wanted, but it was unclear how to get them. I've added this to the RFE list. > Was this broken in SVN 1.5 too? I didn't see anything in the change log > for 6.0.7 that addressed my issues. Do I need to upgrade still? By the > way, when I updated from 6.0.3 to 6.0.6 (win XP), it refused to update > one of the .jar files in the lib directory. I reinstalled about 3 times > and eventually had to reboot, delete the files manually, then install. > All previous installs had gone smoothly. There have been two changes in SVNKit since SmartSVN 6.0.6 release which might be related, so upgrading to 6.0.7 is definitely recommended. Regarding server version, according to: http://subversion.tigris.org/svn_1.6_releasenotes.html tree conflicts might not be detected, so 1.5 server should be no problem. Did you actually have tree conflicts, i.e. the corresponding directory/file was not in "pure" conflict state, but still showed up a red exclamation mark? See: http://www.syntevo.com/smartsvn/documentation.html?page=directory.badges http://www.syntevo.com/smartsvn/documentation.html?page=file.badges -- Best regards, Marc Strapetz ============= syntevo GmbH http://www.syntevo.com http://blog.syntevo.com Jason Hughes <jhughes@...> wrote: > I'm using SmartSVN 6.0.6, and I think my SVN server is 1.5. Updating > that will be difficult, but not impossible. > > > >> > - switch back and forth and watch SmartSVN cry and moan about folder > >> > conflicts > >> > > > > With SmartSVN 6.0.7 I've tried to reproduce, taking following actions, but > > failed: > > > > - Create directory "dir1" > > - Create file "dir1/file1.txt" > > - Create file "dir1/file2.txt" > > - Ignore "dir1/file2.txt" > > - Commit > > - Create branch "conflict", switch to branch > > - Create directory "dir2" > > - Move "dir1/file1.txt" to "dir". > > - Commit > > - Switch to trunk: No conflict > > - Switch to branch: No conflict. > > > > > > > I'm not sure if I did the move of files within SVN or if they were > deleted and re-added manually. In either case, having an ignored file > in the folder that is deleted is critical to reproduce, because it > causes the folder to stick around even when the switch to a different > branch would otherwise delete it. > > >> > Issue #1: If I have set a file to be ignored in a directory, I realize > >> > that directory cannot be deleted because it isn't empty. > >> > > > > I know this behavior, but I think only from older versions. With 6.0.7 you can > > remove directories containing ignored files. SmartSVN would only complain in > > case of modified/unversioned file. You may also use "Force Removal" to get > > even rid of these files. Probably this is the reason why I don't get conflicts > > for the same(?) situations where you had conflicts. > > > > > > > I don't think Force Removal is what I want. There may be legitimate > reasons for keeping ignored files in a folder... such as there being a > 500mb video file that doesn't belong in SVN, but it needs to be there > for my application to work. I just want SVN to ignore that it is > there. I do NOT want it to delete that folder. I want it to allow for > a local folder to exist that doesn't actually have a conflict with > whatever a branch wants to put there. Different behavior entirely. > Force Removal doesn't sound like it does this. > > >> > Issue #2: I do not EVER want to see a partial fetch during a switch. > >> > The whole reason for using atomic version control is that either > >> > something succeeds or it fails. Half of my folders are switched and > >> > half are back on another version. This is totally broken in every > >> > imaginable way. > >> > > > > SVN doesn't claim to have atomic update (but only commit). Indeed, > > update/switch can fail due to multiple local "conflicts"/obstructions which > > have to be resolved manually (hence SVN has to leave the working copy > > partially switched). But if update/switch is interrupted by a conflict, a > > couple of directories (including the root) should remain in "incomplete" state > > and AFAIK a simple update on the root will proceed with the initial > > update/switch. > > > > > > Okay. I think it would be the best goal to aim for, though. If a > switch fails, it should tell me why, but it should either 1) continue > trying to switch the rest of the project as I told it to (which it > doesn't), or 2) roll back all the changes it made thus far except for > the conflict, or 3) put all the changes into a change set so I can roll > it back if I want to get back to a pristine copy. > > One of the severe problems I ran into was I could not get to ANY valid > version of a branch or trunk because folder conflicts prevented it. I > tried to switch both directions, I tried reverting, and in the end I had > to manually resolve a bunch of stuff that ended up costing me a day > worth of work to figure out. > > OH! And by the way, the terminology in the Resolve menu is horribly > ambiguous and vague. It should not say some fixed string, like pristine > this or before that or pristine the other. It should simply say "Take > [branch xyz]", "Take [trunk]" or "Take merged". I screwed up several > files just trying to understand the language being used in the dialog > box, not really that I didn't know what I wanted to happen. I knew what > files I wanted, but it was unclear how to get them. > > >> > I'm also getting a ton of 'local add, incoming add upon merge' with > >> > folders that are created from a branch. > >> > > > > OK, these are tree-conflicts and AFAIK since initial SVN 1.6 release there > > have been some fixes. Without concrete examples it's hard to tell whether the > > conflicts your were running into are justified or not. I would recommend to > > upgrade to version 6.0.7 which might fix some of your problems (btw, which > > version are you using currently?) > > > > > > Was this broken in SVN 1.5 too? I didn't see anything in the change log > for 6.0.7 that addressed my issues. Do I need to upgrade still? By the > way, when I updated from 6.0.3 to 6.0.6 (win XP), it refused to update > one of the .jar files in the lib directory. I reinstalled about 3 times > and eventually had to reboot, delete the files manually, then install. > All previous installs had gone smoothly. > > JH > > > [Non-text portions of this message have been removed] > > > > ------------------------------------ > > Yahoo! Groups Links > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/smartsvn/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/smartsvn/join (Yahoo! ID required) <*> To change settings via email: mailto:smartsvn-digest@... mailto:smartsvn-fullfeatured@... <*> To unsubscribe from this group, send an email to: smartsvn-unsubscribe@... <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ |
| Free embeddable forum powered by Nabble | Forum Help |