RFC: dealing with dead, anonymous feature branches

Martin Geisler mg at aragost.com
Mon May 17 10:13:37 CDT 2010


Augie Fackler <durin42 at gmail.com> writes:

> On Mon, May 17, 2010 at 8:57 AM, Martin Geisler <mg at aragost.com> wrote:
>> Augie Fackler <durin42 at gmail.com> writes:
>>
>>> We run the risk of losing tags if we stop transferring some branches.
>>
>> I see... You must be talking about the situation where we have
>>
>>  [A] --- [B] --- [T] --- [C]
>>             \
>>              [X] --- [Y] --- <Z>
>>
>> and T is the changeset that adds a tag for Y and Z is dead. If I
>> clone this, I will only get A, B, T, and C and the .hgtags file will
>> still reference the unknown Y.
>
> Oh, hadn't even thought of that situation. I was more worried about T
> adding a tag for Y but C is dead.

That is okay -- that is equivalent to me cloning only Z and today I will
also not know about the tag for Y added by T.

>> Perhaps this suggests that it is a very bad idea to make a tag on one
>> branch that refers to a changeset on another branch (again, "branch"
>> means topological branch here). The normal case where you do
>>
>>  hg tag 1.0
>>
>> to tag the current working copy parent revision works fine -- if you
>> have the tag, then you also have the changeset it refers to.
>>
>> So can we forbid tags that "cross branches" like this?
>
> Not sure. hgsubversion uses the fact that closed branches hang around
> in order to emulate Subversion's mutable tags, so there are converted
> repositories that probably look something like this...

Now that I think of it, the scenario where T adds a cross branch tag for
Y is already a problem today: if I only clone C, then my .hgtags file
has a dangling reference to Y.

In other words: the consequences of dead branches are not new. All that
changes is the heads that are pushed/pulled by default and you can
already get yourself into the same problems today with 'hg clone -r'.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/


More information about the Mercurial-devel mailing list