Dividing up the work of a large code merge among multiple people?

Question

This question is related to this one:

Why not commit unresolved changes?

When needing to merge a large code base with many conflicts, I would like to have a way to commit progress to be shared across a team of people executing the merge while maintaining the ability to use all our merge tools during the process. We happen to use mercurial, but this is really a general DVCS question.

The process we have chosen to use, but don't like, is that we make a share-drive and divide the work by assigning specific sets of files to individuals or sub-teams. We're all then working live in a "local" but network-shared location, all editing files directly. The only enforcement of good behavior is trust and there's no way to commit and track our progress beyond zipping it all up each evening. In short, our chosen process abandons the benefits of repository management while resolving merge conflicts.

One alternative is to unmark all the files and commit them with the conflicts. But this is disconnects the merge process from the merge tools and resolving conflicts becomes a hand-editing exercise. We've decided this is worse than the above chosen process because it disconnects us from the tools of merge and conflict resolution.

Is there a better way?

Thanks.

Answer 1

Note: I haven't personally used Mercurial, but the general approach should be the same for any kind of version control system.

Huge merges should be avoided for exactly the reason that you're seeing right now. Perhaps this episode would a useful example deterrant for all future work, and an illustration of how important it is to merge on a regular basis.

Create an intermediate merge branch from your latest trunk revision.

• You can freely destabilise it during your merge without affecting the trunk.

• You can do partial merges and then combine those parts into a single commit later. (I believe this requires a plugin for Mercurial)

• You can (more easily) divide the merge among multiple team members and check-in whenever its convenient.

• You can check-in code which doesn't work or compile, but as with any branch, its best to check-in code which is as complete as possible.

• If your attempt to resolve a conflict creates a mess then you can refactor it in the intermediate branch without affecting the trunk.

• If merging too much at once causes problems, you can rollback and try to merge fewer changesets; again without making a mess of the trunk history.

• You can resynchronise the intermediate branch with the main trunk at any time to catch any changes which have happened in the meantime, and resolve those conflicts too.

• Once your merge is complete, you can complete additional work packages for "broken" functionality that needs re-implementing (e.g. requirements conflicts, or code which has been superceded in your latest trunk).

• You have better control over the way history appears in the trunk for the final merge

Think of the intermediate merge branch as a "sandbox" in which you can create a temporary mess without polluting the trunk, so long as you clean it up afterwards, and finally merge that cleaned-up version into the trunk, then remove the sandbox.

Remember that a merge shouldn't be an excuse for creating more messy code. After you've resolved your conflicts, you should refactor as necessary, get it peer-reviewed, and all the other things you'd be doing when committing new code to keep it at least as clean as the way you found it.