Tagging idea

[Martin Geisler]

Wagner Bruna <wagner.bruna+mercurial at gmail.com> writes:

> I believe Matt is referring to a message (deeply) inside that thread:
>
> http://selenic.com/pipermail/mercurial/2009-January/023345.html

Thanks a lot for digging that out! Let me repeat it here:

Matt Mackall writes:

> Look, folks, there are precisely 4 ways to implement tags:
>
> a) part of changeset itself
> b) outside of history
> c) in a separate history
> d) inside of history, pointing backwards
>
> Type (a) are immutable and uneditable and must be added at commit
> time.
>
> Type (b) don't have a change history and require an additional
> transfer mechanism.
>
> Type (c) means you have to have a complete set of duplicate methods
> and commands for examining tag history and also require an additional
> transfer mechanism.
>
> And type (d) are restricted to only point into the past. Which means
> we have the clone -r problem.

That is true, *unless* we always clone the commit with the backwards
pointer. Our current scheme makes it easy for me to add a tag to an old
revision. The changeset where I edit .hgtags (the "tagging changeset")
is therefore far ahead of the changeset that I'm referring too (the
"tagged changeset"). That makes it a bit weird to bring that changeset
in when one asks for the tagged changeset.

But we can put the tagging changeset anywhere we want, and the proposal
is to put it right after the tagged changeset. That's basically it, with
the addition that there is no backwards pointer any more.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20091106/57a8914d/attachment.pgp