managing multi-version development with mercurial

[Mike Jarmy]

On Tue, Dec 1, 2009 at 3:07 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> First, you want to read
> http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/,
> which has a lengthy but quite thorough overview of all the branching
> strategies Mercurial has on offer. I think the
> named-branch-per-version approach sounds good for your scenario.

Yeah, I actually read that before posting.  I just felt like I wasn't
quite grasping it completely.

> For your specific questions: transplant is the most streamlined way to
> do cherry-picking. Multiple repositories are actually just another way
> of branching, but I hope that becomes clear from the link I offered.

I've been playing with transplanting in a toy environment this morning
and it seems to do just what I want it to do.  Named branches would
clearly seem to be preferable for us over 'heavy-branched' multiple
repositories.

> For forward-porting branches, the nicest solution IMO is to commit
> fixes to the oldest branch where you want them, then just hg merge
> them into the newer branches. Queues are nice for developing patches
> by a single or small group of developers (or in a scenario where you
> want each changeset in the real repository to build/test cleanly), but
> you probably don't want to keep code in them for the longer term.

We will need to think hard about which 'older' branches are safe to
merge from and which aren't.  Is it possilbe to set up some sort of
hook policy to disallow merging except from dedicated mergable
branches?  I have a half-formed idea in my head involving naming
conventions for branches, and possibly even changeset messages.  Can
you inspect a changeset message from a pre-commit hook and reject it
if its going onto the "wrong" branch?  Maybe I'm overthinking this --
I guess I'm just paranoid about the inevitable confusion if/when we do
the switch (no matter whether its hg or git).

> I think the flow probably wouldn't be fundamentally different from
> what you'd do in git, except that in hg (if you use named branches),
> you can actually see which branch a cset got committed to.

Sounds good.

>> http://stackoverflow.com/questions/265944/backing-out-a-backwards-merge-on-mercurial
>
> The solution if you haven't pushed yet isn't so hard, in hg either.
> Not sure what git reset does, but with hg strip (from the mq
> extension) you'll be able to remove the latest two csets from the
> local repositories (make them disappear forever) and retry the merge.

Yes, 'hg strip' seems to do more-or-less what 'git reset' does, and it
seems to work just fine.  Upon re-reading the above link, I think the
guy who created the thread is having all sorts of problems with
colleagues *pushing* bogus merges, which then get propagated all over
before anyone sees that there is a problem.  I am not aware of how you
could fix that easily in git either.  Thats why I'm interested in
perhaps using hooks to somehow impose order; maybe its not really
necessary in practice though.

I found that link inside of the hg wiki, at the bottom of
http://mercurial.selenic.com/wiki/NamedBranches.   In the wiki, it
says "Mercurial does not yet offer a foolproof way to back out an
erroneous merge."  Perhaps It would be more accurate if the wiki said
something like "Unpushed merges (and any other unpushed cset) can be
fixed with the use of 'hg strip' and <insert_other_technique(s)>.
However, once a merge has been pushed, and someone else has pulled it,
Mercurial does not yet offer a foolproof way to back out the merge."

Mike Jarmy