3

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.

  • 8
    Seems to me like the best solution is to avoid the large merge conflicts in the first place, by using a better process of branching and merging more frequently. You're not "avoiding" the merge conflicts; you're just putting them off. – Robert Harvey Mar 17 '16 at 15:13
  • +1 R.H comment. ".. more frequently..." says it succinctly, @BenCottrell more thorough answer notwithstanding. No matter what your repository management plan you must commit frequently. At first, proper use of the tool will seem counter-intuitive but you must make that crucial "version control leap of faith" and use Mercurial as intended. P.S. from my old-head perspective modern distributive version control tools are truly liberating. P.P.S. google "forward integration" – radarbob Mar 17 '16 at 18:32
  • I completely agree. But, that doesn't stop it from happening with multiple branches off doing orthogonal work under high pressure. The large merge problem is not going away. – PaulRuby Mar 18 '16 at 13:50
2

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.

  • This is exactly something I'm looking for but can't find: "You can do partial merges and then combine those parts into a single commit later. (I believe this requires a plugin for Mercurial)" – PaulRuby Mar 18 '16 at 13:46
  • I should add that the intermediate merge sandbox is how we isolate the merge. The problem is that merge is a monolithic event requiring many people to work on all in parallel to achieve a single repository commit. Our current solution is a a share drive and a gentleman's agreement on who is working in what files. – PaulRuby Mar 18 '16 at 13:54
  • @PaulRuby I managed to find this for combining commits in mercurial - Can I squash commits in Mercurial? – Ben Cottrell Mar 18 '16 at 14:45
  • With the ability to combine those commits, I'd think you could have each developer working in their own local copy instead? – Ben Cottrell Mar 18 '16 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.