branch handling

Dan Christensen jdc at uwo.ca
Mon Jul 18 01:28:45 UTC 2005


Matt Mackall <mpm at selenic.com> writes:

> On Sun, Jul 17, 2005 at 01:35:18PM -0400, Dan Christensen wrote:
> 
>> What about the following approach:  Have something called a "moving
>> tag".  The user can tag a specific version with a moving tag.  Then,
>> anytime a node is added to the repository (commit, merge, pull, etc),
>> each of its parent nodes is searched for moving tags, and all the
>> moving tags are *moved* to the new node.  
>> 
>> The result is that when a branch gets split, the first ancestor is
>> the one that inherits the moving tag, and its future siblings don't.
>
> Forks happen a) constantly and b) on separate machines. It's better
> for tags to just stay put. There's no good solution to the split
> branch tagging problem because in Mercurial _everything_ is a branch.
>
> More importantly, 99% of merges are going to be between the two heads
> closest to the tip, without reference to any labels. And my scheme of
> simply propagating tags out to heads solves most of the remaining
> pain. So there's just not a lot of value to adding complexity here.

My solution is in some ways simpler that what you propose.  It's just
an O(1) operation at commit time, and for almost all purposes, the
moving tags work like regular tags, e.g. at any given time, the moving
tag points to a single revision.

I don't see a problem with the frequent and distributed branching.
Just like "tip" means different things in different people's hg
repositories, "main-tip" will mean different things at any given time.
But the typical graph will have most branches merged back together,
and so whenever people sync up, they will then agree on "main-tip".

Here's the scenario I'm imagining.  Suppose that tomorrow, someone
finds a security bug in 0.6b which needs to be fixed quickly.  The bug
doesn't affect tip, because of some restructuring that has taken
place, but you want to release a bugfix-only update to 0.6b so Debian
et al can quickly update their packages.  So you checkout 0.6b, make
the fix, and check-in a new revision you tag 0.6c.  At this point 0.6c
is the new tip.  Some new potential developer comes along and says "I
wonder what the current state of development is".  She checks out the
tip version, only to find it doesn't have the beginnings of a GUI, so
she goes away.  Even worse, someone else who is an active developer
might accidentally merge from "tip" and get 0.6c instead of the latest
development.  

If sometime early in hg history you had tagged the tip as "main-tip",
a moving tag, then that tag would point to the development head, not
0.6c, since it came later.  The docs could tell newcomers to check out
"main-tip" if they want the current development version.  And the
frequent developer could specify a default option of "-r main-tip" in
their config file to indicate that they want to follow the development
branch by default.

With your "all ancestors" approach, both 0.6c and the "real" tip
inherit the "main-tip" tag, which seems confusing to me.

Moving tags are supposed to be less stable than regular tags,
but more stable that the pseudo-tag "tip" which can jump around
to very distant branches.

Just some thoughts...  I don't have much experience with hg yet,
so thanks for putting up with my rambling.  Tossing ideas out
is a good way to learn.

Dan



More information about the Mercurial mailing list