Is there a workflow in Mercurial that enables many people to work on a merge (integration) together?

Question

Say you have two “main-line” branches that have been developed separately for a long time, when you come to do the merge between them, you wish to split the work other all your developers.

E.g. you wish your C# programmer to merge the C# cope, while your TSQL programmer is merging the stored procs.

I wash all developers to be able to see what still needs to be merged and the results off each other merges, can Mercurial help with this?

[I am assuming there is more than one developer left after they have been told that they will have to do the merge!]

---

As I have been asked in the comments, this is how I think we got into this state…

If I understand the history correctly from before I joined. One large customer came along and said “we will pay you a lot of money if you add x,y, and z to your product, but we are not willing to take the risk of you giving us any changes that we don’t directly benefit from (they even put some of their own programmers on the team to check they were not getting other changes).

In the few years that the work was going on for this large customer, other customers said they would not buy the product if we did not add, a, b, and c”.

The large customer was not willing to pay for x,y,and z to be done in a way (or to be able to be turned off) that did not break the product for other customers that used it in different ways, and most of the programmers that understood the system where being sold to the large customer, so there was no man power (until now) to fix x,y,and z so they could be given to all our customers.

(Basically trying to build a product based on consulting income - the fact that we were brought by a company that is closely related to the large customer in the meantime just make the politics more complex.)

At the time all this started the product did not have much automated test coverage, the code base goes back to when .net v1 shipped and all the features are well integrated both in the UI and in the source code.

Hopefully history will not repeat itself, but it is very hard for programmers to say NO in a City that does not have many software companies. We are now moving to Mercurial, and I wish to know how we could cope with Mercurial if history did repeat itself! (I am also starting to question if Mercurial is all it is made out to be compared to Perforce)

Answer 1

One sensible approach could be to use hg convert to split the repository into smaller parts (C# part, TSQL part etc), perform merges on those smaller and more fine-grained repositories, and (if keeping original repo is of importance) just commit the results back onto original repository once they are ready.

Answer 2

Probably the closest to what you want to achieve is to merge one change-set at a time. This avoids the big bang merge by doing lot's of little merges. If you have a clear separation between your C# devs and TSQL devs (which is sounds like you do), then you should be able to allocate each change-set to the right group.

The big negative with this approach is that you won't be able to speed up the process by doing change-sets in parallel.

The big positive with this approach is that you can test after each merge (or a small set of merges), making it easier to track down the changes that break your application. If you don't currently have a strong automated test suite, I would strongly recommend beefing it up first.

Answer 3

Yes, there is a workflow for that scenario.

Plan ahead, know before you branch which branch will merge into which later on, and make sure you merge into it regularly.

Example: You have the default branch, and create a feature branch that at some point should merge back into default. Periodically, merge from default into your feature branch to ensure it is up to date with all changes in default. This creates smaller conflicts along the way. At the end, you do one last merge into your feature branch, fix any conflicts, and then merge it into default.

This avoids "The Big Merge" at the end and creates conflicts that are easier to manage.