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)
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.