Update from svn without merging automatically

问题

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).

回答1:

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.

回答2:

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

edit: I'm copying the linked answer in the FAQ to protect this answer from link rot:

Some people don't like the fact that Subversion merges changes from others with their own local working copy changes automatically on update. Here's how to force those files into a conflicted state so you can merge manually at your convenience.

In TortoiseSVN->Settings->Subversion configuration file, click on the edit button. Change the [helpers] section by adding

diff-cmd = "C:\\false.bat"
diff3-cmd = "C:\\false.bat" 

(note the double backslash) Create the file C:\false.bat which contains two lines

@type %9
@exit 1 

This effectively makes auto-merge fail every time, forcing the file into conflict.

The reason for the curious type %9 line is that the diff3-cmd sends the merged output to stdout. Subversion then takes this and overwrites your local file with the merge results. Adding this line avoids getting an empty local file.

回答3:

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.

回答4:

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.

回答5:

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

回答6:

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.

回答7:

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.

回答8:

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.

回答9:

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.

回答10:

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.

回答11:

education seems to be the only true answer in this case

来源：https://stackoverflow.com/questions/1273113/update-from-svn-without-merging-automatically