How to work with branches

[Alpár Jüttner]

On Tue, 2008-04-08 at 10:12 +0200, Gilles Moris wrote:
> On Mon April 7 2008 22:08:55 Benoit Boissinot wrote:
> > On Mon, Apr 07, 2008 at 04:14:31PM -0300, Martin Marques wrote:
> > > Benoit Boissinot escribió:
> > >> On Mon, Apr 7, 2008 at 10:47 AM, Alpár Jüttner <alpar at cs.elte.hu> wrote:
> > >>> Instead of using transplant, I would suggest another approach. Namely,
> > >>>  commit the bug fix on the top of the changeset where 1.7 forked from the
> > >>>  trunk and then merge it to both branches with two merge commits. The
> > >>>  rationale could be that if a bug exists in both branches, then probably
> > >>>  it already existed at the point of the fork, therefore it is reasonable
> > >>>  to fix it there.
> > >>>
> > >>>  Do you think it a good idea? (I've never used it in practice).
> > >>>
> > >> That's what is done for mercurial itself (hg vs hg-stable). Bug fixes
> > >> are applied to -stable
> > >> if they're relevant, then they are merged back to hg.
> > >> The invariant is that hg-stable is always a subset of hg.
> > >
> > > But are they both together in the same .hg? AFAICS, no. But maybe I'm 
> > > missing something.
> > 
> > No, they are separates clones, but clones are a kind of branch, the
> > naming is just informal (the directory name).
> > 
> > So for example since we don't keep old stable branches, when a new
> > release is made, Matt pull hg into hg-stable.
> > 
> > regards,
> > 
> > Benoit
> 
> If all bug fixes are applied from the fork rev, this will make the history very
> difficult to read, because it won't be linear at all, as underlined by Alpar.
> And there will be a different merged changeset for hg and hg-stable.

Yes, in that case there must be two merge changesets. I made some
experiments, you can find the result here:

http://lime.cs.elte.hu/~alpar/hgwebdir.cgi/branch-test/

This is indeed very far from being linear, but not as difficult to read,
at least if you clone it to yourself and evaluate it with 'hg view' or
'hg glog'.

For example you can see that the release tag 'test-1.7' is in revision
7:d17b1c5efa3f and the branch called '1.7' forked at revision
6:491294d2bb53. If you list the children of revision 6, you can
immediately see all the bugfixes that are applied to both branches (i.e.
to default and to 1.7).

Moreover, you can easily separate the branches by

hg clone -r default branch-test branch-test-default

and 

hg clone -r 1.7 branch-test branch-test-1.7

These sub-repositories look more-or-less 'linear' and they also make it
easy to understand what is happening in the branches.
You can also find these sub-repos on-line:
http://lime.cs.elte.hu/~alpar/hgwebdir.cgi/branch-test-default/
http://lime.cs.elte.hu/~alpar/hgwebdir.cgi/branch-test-1.7/

> Overall, I still do not understand the workflow of changesets from the crew to
> hg-stable, and how the push/pull are initiated.

I do not understand it either.

> I did not found any Wiki page
> on the topic so I guess it does not yet exist. The DeveloperRepos is very vague
> about that. This information could give Mercurial adopters a real life example
> about the process of using a DVCS, with stable and development branches.

+1.

Regards,
Alpar


> Regards.
> Gilles.
> 
> 
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial