Conflict while updating local repository using TortoiseSVN: what do the context menu items do?

Question

I sometimes get conflicts when updating my working copy in TortoiseSVN, as I'm sure many of you do, and I just got rather confused with the options available in Tortoise's context menu. (I must have double-clicked so far...)

Can someone please explain what the first three menu options are good for?

Here is what I think they do:

"Compare with working copy"
I thought this would compare what i have locally with what is currently in the HEAD revision on the server. But now I'm not sure anymore. Is it comparing what I currently have in my WC versus what the code looked like when I checked it out (i.e. WC vs. an old revision)?

"Edit conflicts":
HEAD vs. WC?

"Mark as resolved":
Not sure when I would use this?

Unfortunately, the docs don't seem to mention the context menu: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-update.html

Answer 1

When a conflict occurs, several files are created. The ones with the .rNNNN extensions are pristine copies of the file as it existed at those revision numbers (typically these are the common base and "theirs" changes). The original file is also updated to include <<<>>> conflict markers in the appropriate spots, so that you can use an editor that understands conflicts (or one that doesn't, if you want to handle it manually) and feed it just that one file (although this is typically not the best way to do it, but it's what some people are used to).

Edit conflicts typically opens a three-way merge, showing the "base" (the version that both your changes and their changes have in common, "theirs" (their changes), and "mine" (your changes), and the final merged result. You can use this to inspect and interactively resolve the conflicts. This is usually the best choice, which is why it's the default. (The built-in TortoiseMerge does a decent job at this, although it's possible to use other tools -- I use kdiff3.)

Mark as resolved tells SVN that you have already (through some other editor or tool) resolved any conflicts in the "real" file (the one with the same name as before, that had the conflict markers). SVN will verify that the file no longer contains any conflict markers, and will then delete the extra files and mark the original as resolved without editing it further (as it assumes you've already done anything necessary).

Resolve conflict using theirs/mine do what they say on the tin; they replace your copy of the file with the complete file from either their changes or your original (pre-update) changes, ignoring any changes that came from the other side. While this is sometimes useful it runs the risk of losing changes made by others (or yourself), so you need to be careful with it.

In all cases, the resolved changes are made only to your local working copy. This still allows you time to verify the result (eg. build and run tests) before you commit again.

Answer 2

To expand my comment a little more -- two people making the same exact change results in a conflict. Supposed we have the following in file A

ScreenList screens = {Screen1, Screen2, Screen3};

No supposed in File B we have

ScreenCount = 3

Now I edit File A and add Screen4 and update Screen count in file B to 4. I check in my changes.

Then you edit file A and add Screen4b and update the ScreenCount in file B to 4.

You then merge in my changes and we now have in file A:

ScreenList screens = {Screen1, Screen2, Screen3, Screen4, Screen4b};

but when we get to file B we both have the same thing

ScreenCount = 4

What we really want here is

ScreenCount = 5

So, we both made the exact same change to the file but it really is a conflict -- a case where manual intervention is required.

The example is a little contrived and you can come up with examples where two people making the same change does not result in a conflict. The point is that Subversion has no way of knowing which case it is, hence a conflict.