tags and multiple heads

Georg gwk.rko at googlemail.com
Thu Jun 12 16:35:43 CDT 2008


IMHO the central uncertainty here is space and time.

When you update (change) a tag on one branch, we don't know whether you ever
saw a tag update on another branch.  That other branch may be on a different
continent and may not be merged until two years from now.

So when we have two heads exhibiting different definitions of a tag, there
just is no 100% correct way of picking the "right", "latest", "current"
definition.

The best attempt that Hg makes at this point is assuming that a branch that
had tag definition 1 (the tag points to rev 1) in its own (this branches)
history, and then later in this branches history the definition was changed
to 17, then 17 is more correct than 1. It was changed from 1 to 17, so we
know (assume) 1 is obsolete.

That assumption still holds if tag definition 1 is reapplied a thousant
times, "later", in the other branch which never saw the 17.  We just don't
know and cannot make assumptions at this point that the first branch (the
one that had put the 17) was "abandoned" and the second branch is now "more
correct".

I don't see how this could be improved, as long as we are ready to accept
that Hg is a *distributed* VCS. One branch cannot assume anything about
another branch, the other may live on another continent and at a different
time scale. Einstein was right, there is no universal time :)

--
Regards,
Georg.

2008/6/12 Henryk Gerlach <hgerlach at gmx.net>:

> Hi,
>
> I don't understand how tags are handled in multiple heads. The wiki (
> http://www.selenic.com/mercurial/wiki/index.cgi/Tag) says:
>
> The tags that are in effect at any given time are the tags specified in
> each head, with heads closer to the tip taking precedence. Local tags
> override all other tags.
>
> But this behavoir has changed by:
> http://hg.xavamedia.nl/mercurial/crew/rev/e29f2db5ab18
> due to http://www.selenic.com/mercurial/bts/issue498
> the implemented Algorithm seems to be discribed here
> http://www.selenic.com/mercurial/bts/file248/hgtagfix-gwk-take4.patch-annotated
> .
>
> Can someone confrim this so I can document it in the wiki?
>
>
> Plus it looks like it is not handeling the nullid-cancling(*) of tags
> appropriately, which IMHO causes
> http://www.selenic.com/mercurial/bts/issue1102 (**)
>
> (*) the nullid-canceling seems not to be documented in the manpage nor the
> wiki.
>
> (**) It looks like truncating the tag history when encountering a nullid
> seems the appropiate measure:
> =======================================
> diff -r d1a312daa574 mercurial/localrepo.py
> --- a/mercurial/localrepo.py    Wed Jun 11 18:00:58 2008 -0500
> +++ b/mercurial/localrepo.py    Thu Jun 12 19:03:13 2008 +0200
> @@ -260,7 +260,10 @@
>                 h = []
>                 if key in filetags:
>                     n, h = filetags[key]
> -                    h.append(n)
> +                    if bin_n == nullid:
> +                        h=[] #truncate history for deleted tags
> +                    else:
> +                        h.append(n)
>                 filetags[key] = (bin_n, h)
>
>             for k, nh in filetags.items():
> =========================================
>
> Best regards,
>
> Henryk Gerlach
> --
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080612/4f98d807/attachment.htm 


More information about the Mercurial mailing list