Resolving a merge conflict when I do svn update

Question

I am trying to learn basics of version control by Eric Sink - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf

I am on page 22 now. I\'ll describe the scenario for you. Two

Answer 1

When you have multiple people changing the same file at once, it's very possible for both to change the same lines. This is what happened to you. Sally changes the same lines Harry was changing. When Harry did svn update, Subversion detected this, and is asking you what to do.

A word of warning: Sometimes Subversion is only looking for differences in a line between your version and their version, and not meaningful differences. For example, if the indentation of a line was changed, or spacing was different, or if you changed the line endings, Subversion will declare this as a conflict even though it probably isn't. This maybe why the book didn't find this issue, but you did. Doesn't mean you did anything wrong.

What to do? Subversion is giving you a few choices.

• postpone p: This is what I usually do with this type of situation. Subversion will embed in the file diff markers that look like this in the file:

 

<<<<<<< .mine
foobar
=======
fubar
>>>>>>> .rxxx

This is showing you the changes in revision rxxx (what Sally did) look like vs. the changes you have (Harry's changes). Usually, the changes are minor enough that it's pretty easy to figure out what to do.

• show diff df: This will show you the differences between your changes (Harry's) and what's in the other revision (Sally's). It basically shows you the diff markers.
• edit e: You can edit the merge conflict as you do the merge instead of waiting till later.
• merge m: Not too sure what this does. You're doing the merge right now, so this doesn't make too much sense.
• their side of conflict tc: Accept what Sally did in order to resolve the conflict. You probably have to redo your changes, but at least you're considering Sally's changes.
• my side of the conflict mc: The most dangerous scenario because you're completely ignoring Sally's changes. Sally did a fix, and you're possibly unfixing it. When the release comes out, and Sally's fix isn't in it, you will be blamed for removing the change. So, why do you do this? Because you already looked at the changes, and realized the conflict really wasn't much of a conflict. It was a change in indentation or something similar. Or you called a variable increment and Sally called it counter.

As I said, I usually do a postpone, let my update finish, then handle the problems.

Once you fix the problem, you do a svn resolved on that file to let Subversion know you've fixed the conflict.

There are further choices -- for example, you can launch a third party diff/merge tool to handle the conflict.

For more information, take a look at the Subversion on line manual about resolving merge conflicts.