Anyone who is working in a team and using a half-decent version control system will have come across merging. If not, then you've been lucky.
Merging conflicting files frustrates many developers. And I reckon that this is because there is a fear that the merge will not be performed properly, resulting in a loss of work.
Today I came across the merge from hell. I performed some work for one of my clients, but the work was done against an old version of their source code. When they discovered this, they sent me the latest copy of the code and asked me to apply the changes again. I tried to merge the changes with this latest copy of the source, resulting in plenty of merge conflicts. I am not sure whether I performed the merge correctly.
Fortunately, there is a technique that one can employ that allows one to start a merge over again if an error was made in the merge process. I'm using TortoiseSVN and a Subversion server with KDiff3, but this might also be possible with other tools.
With TortoiseSVN, whenever a merge conflict occurs, TortoiseSVN will save a copy of the "base" version (ImportBase.cs.merge-left.r7), "mine" version (ImportBase.cs.working) and "theirs" version (ImportBase.cs.merge-right.r12) on your hard disk. TortoiseSVN appends the revision numbers to the file name, like in the picture below. These files remain on the hard disk until you mark the conflicting file as resolved.
When you open the conflicting file (ImportBase.cs in this example), you'll notice that there is a lot of markup using concatenations of less-than and greater-than symbols. This is because TortoiseSVN has saved the conflicting file using the diff-format. I presume that this is to make TortoiseSVN compatible with certain merge tools. With the merge tool that I use (KDiff3), the "mine", "theirs" and "base" files are used to perform a 3-way merge. When the merge is complete, the result of the merge is saved to ImportBase.cs.
Put another way, KDiff3 uses ImportBase.cs.merge-left.r7, ImportBase.cs.merge-right.r12 and ImportBase.cs.working as inputs for the merge process and writes the output of the merge to ImportBase.cs. Therefore, if you've made a mistake, you can start the merge process all over again. That is if you haven't marked the file as resolved.
So here is the technique: Don't mark any conflicts as resolved until you have finished your tests!
tags: SubVersion, Merging, Diff