Branches in general

[Eric M. Hopper]

On Sat, 2007-06-09 at 13:28 -0500, Matt Mackall wrote:
> 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.

Usually I don't want to know this.  I can see some cases in which it's
an event worthy of the world knowing about, but mostly I don't think it
is.

In fact I think this sometimes can obscure important things

> 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?"

I think which question is more useful is dependent on context.

> There is?

Yes, for example when you grab a branch head you can get revisions with
branch comments stating that they're from all kinds of other random
branches.  They just happen to be ancestors of the head of the branch
you wanted.

When you merge another branch into yours, suddenly the revisions on that
branch are part of your branch because they're ancestors of the merge
changeset.

When you create a new branch, suddenly all the changes that are
ancestors of it are on your new branch no matter what branch tags they
may have in their revisions.

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

Well, I might misidentify a head.  I might call something a head when in
reality nobody should ever really develop on that branch from that
revision ever again.  And I might also miss calling something a head
because it doesn't have a branch tag that says it's on that branch, but
from the perspective of anybody who's doing development it actually is a
head for that branch.

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

I don't think either A3 or A5 should be in that graph.  I think at one
point in the history of that repository B3 was a head on A, and at
another point B5 was a head on A.  I don't think A5 and especially A3
tell me anything useful.

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

From things you've said, I suspect that may make merges do the wrong
thing sometimes because of the closest ancestor calculations.  And those
kinds of merge changesets largely feel like useless clutter to me
anyway.

Hmmmm,
-- 
The best we can hope for concerning the people at large is that they
be properly armed.  -- Alexander Hamilton
-- Eric Hopper (hopper at omnifarious.org  http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 185 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20070609/9896e33d/attachment.asc>