Handling Difficult Distributed Version Control System Merges With Pair Programming

Question

A common problem in my very small team workflow is handling merges from trunk/stable repositories up to feature branches which are ahead of the trunk or stable versions, but which need to track the changes in the trunk and stable versions. We are using mercurial, but any DVCS would perhaps have a similar workflow, including Git, or others.

Originally we had a workflow where a senior developer (me) did most of the merging, as that was the model I had experienced at a previous workplace, but similar to the previous place where we worked like that, this put a lot of burden on one developer to take the results of a large number of commits, and clean up the resulting mess.

If you were merging one change, with one commit message, maybe you could do this cleanly, but what often happens to me, is that I get a little behind, and a week of changes needs to be merged.

What I'm wondering is, when you DO get into a situation where a large merge is necessary, using Mercurial or DVCS, what is the process that you use, and does it involve collaboration between multiple developers on the team, and does your team use pair programming to solve this complex programming problem of How Do I Sort Out and Land the Changes from TRUNK that need to get to FEATUREXYZ branch.

The workflow or standard-practice I am envisioning looks like this:

• when a merge up to a feature branch looks easy and only involves my own changes I do it on my own

• when a merge up to a feature branch also pulls in someone else's changes that are not trivial, I involve that person in the merge.

Common sense? I think so. But I suspect that others have been down this road and can offer a more clearly elaborated, and "tried and true" approach for this general situation.

Answer 1

There really is no easy way around it. A fundamental truth about version control is the longer you diverge, the harder the merge. (I should put that on a T-shirt).

There's no reason every team member needs to be involved in the merge every time, but you can rotate it around. If you can't do it one day, make sure someone else does. The more your team is involved, the more they will be aware of incompatibilities growing between the branches, and the less likely they will be to make breaking changes.

You should also look for opportunities to merge into the trunk. You should break long features into intermediate steps that can be safely tested and merged in, even if the entire feature isn't available yet. New features usually require both rework of old code and creation of brand new code. It's the former that creates the most merge conflicts. Luckily, it's also the easiest to change before a feature is complete.

For example, say your new feature requires a certain field of a widely-used existing data structure to be 16 bits instead of 8. You can usually make a change like that in the trunk without adversely affecting existing code. The sooner you do so, the sooner the rest of the company will stop making that particular merge conflict in their new code.

In other words, if you're continually fighting the same kinds of merge conflicts, you should look for ways to fix it in the trunk, if at all possible.

Answer 2

It somehow sounds going backwards.

The feature branch is owned by one or more people. They know what is it all about. They shall manage its state by whatever means convenient.

The branch will be integrated at some moment, the devs may leave it to the final sate or chose to reduce divergence. In any case it semantically looks like they add their changes to whatever point on trunk.

Ideally the rebase (or merge) just succeeds, the branch compiles, tests work, all happy. If it's not the case, again the branch people will go discovering what happened on main, either just looking at history or grabbing trunk devs for info. (The good feature of DVCS is the action can be postponed without hindering work...)

Using PP or reviews to look merge impact? if the delta is non-trivial, sure, why not. But if testing framework is in place it's supposed to catch problems in time before final integration.