Branches in general

Matt Mackall mpm at selenic.com
Sat Jun 9 13:28:25 CDT 2007


On Sat, Jun 09, 2007 at 09:57:42AM -0700, Eric M. Hopper wrote:
> 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.

In some sense it's artificial, yes. No files are touched, etc. In some
sense it's not: declaring that the changes in B3 are now part of
branch A is an event. It has a time, it has an associated user, and it
may have a non-trivial description.
 
> 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.

You seem to be saying that changes B1-B3 are now "on" branch A in
addition to being on branch B. Fine, there's some sense in which
that's true. Every ancestor of the tipmost change of A (eg A5) is, in
that same sense, "on" branch A.

By this definition, the question becomes "what branches do the changes
in changeset X appear in?" Which is a subset of the more general (and
useful) question, "what are the descendents of changeset X?"



> 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.

There is?

> My heads -b code makes fairly explicit use of this heuristic in
> guessing about branch heads.

It does? What's there to guess? A head of the sub-DAG X (aka "branch" X)
is any node in sub-DAG X which does not have descendents in
sub-DAG X.

In your above graph, the heads of A are [A5]. A3 is not a head of A
because it has a descendent A4 in A.

We could modify this definition from "descendent" to "child" which may
simplify the associated algorithm by making "fast-forward" merges have
two parents.

-- 
Mathematics is the supreme nostalgia of our time.


More information about the Mercurial-devel mailing list