Merging Multiple Mercurial Branches Together

Question

I have a bunch of developers who do their bug fixes using branches. My Need: What's the best way to automate (or is there a way) merging all of these branches into one main branch, "default".

Thanks

Answer 1

Note: This is my opinion, there can be multiple opinions here, but at least understand my point here and decide you want it different.

First of all, there is something missing here, and I think this will generate workflow problems for you in the long run.

Merging is not something that should be skipped, or delegated to other people, the developers that work in those branches should merge themselves. They, and probably only they, will know what they did, and how to resolve merge conflicts.

In any way, doing it fully automatic, that's not going to work.

Here's the workflow the developers should use (in my opinion.)

Periodically, for instance every morning, the developers on a branch should check the build server to ensure that the default branch builds. If it does (and it should!), they merge from the default branch down into their own.

This has three major benefits:

1. They always have the latest code in their own branch, and don't get bogged down working around known bugs that have already been fixed in another branch
2. They deal with merge conflicts from other branches constantly, while the conflicts are small, and the changes are still fresh in the minds of the developers that did them.
3. Since you deal with the merge conflicts every day (provided there are any), when you get to the end of the life of that branch, it is almost fully merged with the default branch anyway, so the work involved in merging it back into default should now be cheap, if not free.

At some point they're read to integrate their work back into the default branch (either periodically, ie. partial releases of new features, or at the end, everything is done), and then they do yet another merge from default back into their own branch. This ensures that any lingering merge conflicts are handled by that team, in their branch, before they release it to the rest of the developers.

When they have dealt with any merge conflicts due to that merge, they can merge the other direction, from their branch back to default. At this point, unless someone has managed to merge/push any conflicting changes into default in the meantime, there will be no merge conflicts at all.

Doing it this way ensures that:

1. The developers who do the merges get training in merging
2. The developers who did the changes still have those changes fresh in memory
3. You amortize the work involved with merge conflicts by doing them often, and doing them in small portions.
4. You don't get a big merge-"week" at the end of a project, when everyone has forgotten all the changes, why they were done and who did them

If any of this was unclear, please leave a comment and I'll update/edit accordingly.