managing multi-version development with mercurial

[Dirkjan Ochtman]

Hi Mike,

On Mon, Nov 30, 2009 at 23:14, Mike Jarmy <mjarmy at gmail.com> wrote:
> What all this means is that sometimes we check in changes that need to
> be back-propogated or forward-propogated to other versions, while
> other times we have changes that are applicable to only one version,
> or branch off from that version as a separate product.  I *think* the
> right approach for us is to use named branches for each version in hg,
> out of one big repository, but I'm somewhat confused.  While git has
> one concept that covers everything (use another branch!), hg seems to
> have several related concepts that would possibly need to be used in
> conjunction (bookmarks, anonymous branches, named branches, queues,
> etc).  How do I cherry-pick bugfix commits from one branch onto
> another?  Is my focus on branching misguided?  Are multiple
> repositories actually a better approach here?  If so, how do we
> propogate bugfixes between repositories?  Should we be using queues
> for bug fixes instead?

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.

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.

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.

> Can anyone describe to me what a good workflow would look like in hg
> for the rather-complicated scenario I've described here?  Any help
> would be greatly appreciated.

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.

> P.S.  I've also run across a couple of links while surfing around
> which have me concerned as to whether hg can really deal well with a
> highly branched environment, e.g.
>
> http://stackoverflow.com/questions/265944/backing-out-a-backwards-merge-on-mercurial
>
> Should I be concerned about that sort of thing? If we go with hg, we
> will be switching about 20 people over all at once to the new
> environment.  All sorts of problems like merging the wrong two
> branches together will happen a lot until we get everyone up to speed.
>  It just seems a little odd to me that something that is so simple in
> git (e.g.  "git reset --hard HEAD~2" if you haven't pushed yet) is so
> difficult in hg.

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.

Cheers,

Dirkjan