Merge to live - Part Three - Tracking

This is the third part in the series of articles about merging I started a few weeks ago. In the first two ones I covered fear of merging and then how to handle manual conflicts and why three-way merge does make sense.

Today I'm going to talk a little bit about merge tracking.

Merge tracking, what's in there for me?

If you've never heard of merge tracking... well, welcome to a whole new world. You've probably heard about it after Subversion 1.5 has been released. It has finally introduced merge tracking. It still has some caveats but it is evolving in the right direction.

Many other systems out there have merge tracking since long ago.

Anyway, what does it mean?

Merge tracking is deeply related to version control tools. You can run a file merge in isolation, but with merge tracking you rapidly enter the field of SCM (whether you want to translate it as Software Configuration Management or Source Code Management is just your choice).

Merge tracking is also deeply related to branching, but I'll try to postpone the topic as much as possible.

Have a look at Figure 6. It represents the merge we've been running in the previous samples. We've the original file and then your changes and mine drawn as some sort of tree or graph.

After I merge your changes with mine, a merge link is created telling the system I've merged your changes on mine. Also, I would like to highlight that during this change we modified exactly the same lines of code, so it will be a manual merge... Remember it because I'll use it below.

What's the benefit? First: you know what you've done since your version control system takes care of this information. If you don't have it, it'll be harder to figure out what happened.

Figure 6. The simplest merge tracking

But, let's make another set of changes on our sample files. You can check how our tree looks like after the changes at Figure 7.

You make a new modification and I make another one, and once the two of us are finished, I decide to merge your changes back on mine again.

How does merge tracking help here? First of all, you remember I mentioned above our first merge was not automatic, don't you? So, what's the benefit of merge tracking? It will just merge the changes after the last merge happened, and you won't have to solve the same manual conflict again. It greatly simplify merging because it will let you focus on what's new and you won't have to merge all the old stuff.

Figure 7. A new set of changes and their merges

How does the merge tool know what to merge? In any three way merge you'll need a base (or original file) and two contributors. In the sample highlighted at Figure 7 the version control tool, with the help of merge tracking, will first try to find what's the base file for the two changes we've (two revisions after all).

And how does the system locate it? It will use your tree of versions and try to locate the closest parent revisions of the ones you're trying to merge. The algorithm is known as nearest common ancestor and it is about finding the closest parent of a couple of nodes on a directed graph.

In our sample Figure 8 shows the base or common ancestor for the two revisions we're trying to merge.

Look carefully, if the merge link wasn't there, the parent would be the original revision, and then the merge tool would have to ask you again about the previously solved conflict (the code would be the same at the two revisions but different from the base).

The merge arrow solves the problem allowing the underlying system to correctly identify which one is the new base for the merge.

Figure 8. The base revision or common ancestor for the merge

Conclusion

Well, what's merge tracking after all? As you've just seen, it's just a colorful way of describing a mechanism which ensures your merges are done right. Merging is not only about combining changes together, but identifying the rights contributors in the game. If you fail to identify the contributors, it doesn't matter how cool your three-way merge tool is, it will screw up your code!