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

Answer 2

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.