managing multi-version development with mercurial

[Diego Oliveira]

Hello Mike,

I do prefer hg over git, some time ago I was in charge of something like u
and I'd figured
out that mercurial is the tool for the job. We have a environment like your.


We are using TortoiseHG as our primary interface to mercurial and it has a
very useful
interface that let u easily see the branches ant it's merger. Follows
attached a print.
Each branche has it own color, and u can see cleary where and what the merge
merges.


On Tue, Dec 1, 2009 at 6:07 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

> 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
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>



-- 
Att.
Diego de Oliveira
System Architect
diego at diegooliveira.com
www.diegooliveira.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20091201/f7f7a4a4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: view_changelog.png
Type: image/png
Size: 59741 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20091201/f7f7a4a4/attachment.png>