Update from svn without merging automatically

Question

My coworker has a problem with the way that svn update works, but I'm not sure why, so this question has two sides. First, how to solve his problem the way he wants, and second, should I try to convince him that the way TortoiseSVN does things now is the best way (and if so, how)?

His Ideal Use Case

1. Right click->SVN Update
2. SVN pulls in changes from repository as long as the file hasn't changed in the working copy
3. If both the working copy and HEAD have changed, he wants to be prompted before anything happens, and to do the merge himself (even if it's a scenario where svn would easily figure it out).

I guess it's a reasonable enough request, but the fact that he doesn't want to trust SVN bothers me, although it doesn't really affect me or my work. He's not new to version control, having used CVS, SVN, and ClearCase before. He claims he was able to do this in svn before (also, he is many years my senior).

Answer 1

TortoiseSVN allows editing a Subversion configuration file, so I guess this option can be configured there. You can access it through Settings->General and clicking on "Edit" in the subversion groupbox, on the "Subversion configuration file" line.

As for the moral question, from a purists point of view, he might be correct, but it seems like more manual and error-prone work to me.

Answer 2

Perhaps you can advise him to try out git. git provides a command "stash" to save the state of the working copy before doing an update from the repository.

Quoting from the description in the manual page:

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory.

Answer 3

I used to be very afraid of merges, but I've never seen a case where SVN's automatic merge failed. It can mess up business logic obviously because two edits may logically conflict without physically conflicting, but I don't think it will do an automatic merge unless it's appropriate.

If you don't have regression tests, your cow-orker may be right due to the fact that there is no review of the "Logic Merge"; but if you have decent test coverage it's really not worth the time.

I really dislike SVN's "merge syntax" for conflicts, but most tools seem to hide it.

Answer 4

Assuming you can't convince your coworker to change his mind, this email thread might be of help in forcing Subversion to allow him to do all merging manually:

http://www.nabble.com/Forcing-conflicts-on-svn-update-to21176148.html#a21176148

Answer 5

I think the best solution here might be to make use of the TortoiseSVN client-side hooks that are available. You could use the Start-Update or Pre-Update hook and in the hook script check the local working copy to see whether there are any uncommitted changes, and if so, abort the update.

Answer 6

Perhaps you can convince him to let svn make the changes, and for him to review them before checking in?

I find the command 'svn diff --diff-cmd=kdiff3' useful for exactly this scenario. Though admittedly this is linux and your syntax will vary with TortiseSVN.

Answer 7

education seems to be the only true answer in this case

Answer 8

TortoiseSVN FAQ: "prevent subversion from doing automatic merges".

Answer 9

Select the file in question in Windows Explorer, then Shift+right click on the file, and under TortoiseSVN you will now see a few new options, among them "Diff with URL" -- select the URL of the file in the repository and choose "HEAD revision". This will show your current working copy (which is based on a non-head revision) on the left, and the head revision on the right.

Now you can manually copy changes from right to left (from head to WC), hand-picking which changes belong and which ones don't. After this, SVN still thinks your working copy is based on an old revision. So do an update, but this won't actually change anything (I think), because you've done all the changes manually. Then commit as normal.

Obviously this would be extremely tedious to do for each file, one by one. But if it's just a single file with a few changes, then this might work. Perhaps if it's tedious enough, the person will give in and trust SVN's built-in merge algorithm.

Answer 10

As uncomfortable as your co-worker is with automatic merges, I'm uncomfortable with co-workers who don't do automatic merges. In my opinion it's the wrong mindset. When you don't accept all the repository's changes you are choosing to un-commit code, but doing it in a way that doesn't feel like un-committing. It's a mindset that is prone to introducing and/or reintroducing bugs.

When you review a merge before allowing it, you are thinking in terms of which changes you are going to allow into your code base, when in reality you're deciding which pieces of committed code you are going to remove from the code base. It's a subtle but important distinction.

Of course changes need to be reconciled, and of course committed code may need to be backed out or modified. Failing to accept other people's commits leads one to undo commits without acknowledging that's what you're really doing.

Answer 11

Actually, I think a slight distrust of merging can be a healthy thing. In my view it's a problem with svn that you can't check in your changes as they are and then, once they're safe, merge them. But you can do it manually:

1. Checkout trunk
2. Make changes and test
3. Branch working copy to a temporary branch
4. Commit (phew, your changes are 100% pure and completely safe)
5. Switch to trunk
6. Reintegrate branch (this is the merge step, but your changes are safe in the branch)
7. Commit
8. Delete branch

It adds extra steps to your workflow, but it may just add that peace of mind. It also gives you a close equivalent of tfs's shelvesets.