Question

Hi all, Kiln/Mercurial newbie here, working through the doc on this site and the various helpful resources out there on DVCS and this implementation of it. Background is Subversion/other centralized SVC, so bear with as I pose an architecture question that no post I can find here seems to address.

Assume a basic Stable/Dev subrepository architecture as posited in the last page of Joel's tutorial. (I quibble with Stable > Dev direction, even after lucid illustrations like this one, but that's perhaps for another post.) So I have a Stable pushed to by multiple developers as we finish up a build to release it, and a Dev(el) pushed to by multiple developers, not necessarily the same, as we press on with the future of our work. Since I am so far Stable/Dev Dev/Stable agnostic, I will pose this problem both ways:

1. A Stable developer fixes two bugs in a pre-release version of Stable, while other Dev developers press on with the unrelated future. Turns out that BugFix1 is 100% obviated by a refactor on the Dev side, and has no push "destination"; BugFix2 remains relevant. Accordingly, when the Dev devs pull (or the Stable devs push), only one changeset, the latter should move from Stable to Dev.

2. A buncha crack Dev developers add New Features x, y, z, and z-prime, then find a stupid bug that also applies to Stable, in a file otherwise untouched by x, y, z, and z-prime. How do they push that one fix only to Stable, despite its succeeding a buncha changesets that Stable should not get?

I hope this is a really dumb question reflecting my ignorance, and that some obvious feature of Mercurial resolves this, but honestly, every example of merging subrepositories I've seen is based on examples far too simplistic for such all-too-common real world examples. (This one requires approximately 2 developers working on both branches for maybe 3 hours.) I know that in the best practices of my past centralized SVC experience, the only way to handle a "cherry-picked" (huge non-fan of that term) bug fix across a Stable and a Dev was to apply it as a revision (ack!) in both places, but there's all this talk about Mercurial's magical merging abilities... Can it merge a single changeset to a different changeset timeline, regardless of predecessors? Isn't that two unlike states, and doesn't it fail just like a centralized SVC would? How does distributed help here?

Answer 1

Hi downwitch!

(1) I think the best solution here is to just merge. If bugfix1 is irrelevant, then during merge conflict resolution the changes made by bugfix1 should conflict with something else and the developer who merges -- who should preferably have knowledge of what's happening in both stable and dev -- will know to delete the code generated by bugfix1. This scenario happens quite a lot here on the Kiln team, where we have wildly diverging, experimental feature branches with crazy Mercurial patch queues on top of them, and we rarely have a problem doing a merge. Sure the merge isn't clean but we have three excellent tools to combat that:

• Clear eyes: we do the merges carefully, consulting each other if there are any problems;

• Full hearts: we read each other's changesets, we code review each other's code, and we know vaguely what's happening in everybody's branches. Nobody just branches and does their own stuff without telling anybody else, nobody's Antisocially Coding.

• Can't lose: we have an excellent test suite architecture that accommodates both unit and integration testing. We share it with the QA team, who in addition to the automated tests perform their own human testing.

I think the solution to (1) is ultimately good software practices. There's really no reason distributed would have an advantage over centralized here (although, discussing specifics, I believe mercurial's merge algorithm and directed acyclic graph model of revisions is generally superior to Subversion's and CVS').

As for (2), I believe the correct solution is to graft the bugfix to stable. That way, stable gets the bugfix. If you're concerned about merging from stable to devel after the graft, I wouldn't; Mercurial generally knows what to do when the same change is made to two branches, even if that change occurs in two different changesets. We use graft all the time here for the exact same reason you posed, and we've never experienced any problems.