Branches in general

Alexis S. L. Carvalho alexis at cecm.usp.br
Sat Jun 9 16:28:12 CDT 2007


Thus spake Eric M. Hopper:
> On Fri, 2007-06-08 at 20:19 -0700, Brendan Cully wrote:
> 
> > As you know, I also have my doubts about hg's branches, but I'd be
> > curious to know what the specific drawbacks were, and how current the
> > implementation was. Most of the UI work to make branches halfway
> > reasonable happened after 0.9.3 was released. Some of it is only a few
> > days old...
> 
> 
> Here is one concrete problem...
> 
> A revision can be in more than one branch at a time.
> 
> The specific case of this is fast-forward merge:
> 
> 
> A1--A2--A3        A4------A5
>          \        /       /
>          B1--B2--B3--B4--B5
> 
> 
> So, in this case, what you really did when you merged B3 is that you
> said that B1->B3 are now also part of branch A.  Because Mercurial
> associates one branch per revision, this is not possible to represent,
> and so an artificial revision is created on branch A to represent this.

The problem is not really that hg "associates one branch per revision",
but that the branch name is included in the commit (and, consequently,
in the hash).  Even if we changed things so that a commit could have
more than one "branch comment", you'd still need A4, because you're
still unable to change the "branch comments" of B3.

> Now, when a revision is developed, it is developed on one and only one
> branch.  In this sense, the per-revision branch tag is like a comment
> about the revision.  You're saying "This revision was developed for
> branch B.".  And that can be a useful thing to know, but it is
> inadequate for determining which branch a particular revision is on.

Yes.  See below.

> Currently there is sort of an ad-hoc (mostly because I think people
> started using it without really thinking hard about it) heuristic used
> that if a revision is the ancestor of a revision on a particular branch,
> that revision is on that branch too.

I really don't think it's an ad-hoc heuristic...

How do you define "revision x is on branch foo"?  You can define it as
"x has a branch=foo hidden somewhere in its changelog", but, as you're
noticing, that's not very useful - it tells you that x was developed on
branch foo, but not much more.

A much more useful definition is "branch foo includes the changes done
by revision x", or, equivalently "x is an ancestor of branch foo" (and
in this last definition, I'm using "branch foo" to mean the "latest
revision" with a branch=foo mark - for some value of "latest revision").

I think you're trying to read this:

changeset:   5161:794b039bacaa
branch:      HEAD
parent:      5153:516f41633e20
user:        Brendan Cully <brendan at kublai.com>
date:        Mon May 28 16:44:20 2007 -0700
summary:     Use autoconf instead of "which" to discover MD5 tool

as "revision 794b039bacaa is on branch HEAD, and only on branch HEAD",
which is not necessarily the case.

Would things get better if hg log printed the "branch: <branch>" field
only if a "hg log -r <branch>" would show that exact revision?

Alexis


More information about the Mercurial-devel mailing list