Tagging idea

[Matt Mackall]

On Fri, 2009-11-06 at 20:16 +0100, Martin Geisler wrote:
> 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.

It's still (a). How do you delete a tag in your scheme?

A lot more effort has been expended on just discussing alternate tag
schemes than is warranted by the difficulties of "pull -r <tag>".
Actually -implementing- such a new scheme would add at least another
order of magnitude to that inequality, not counting collateral damage on
users who've had five years of experience with our current scheme.

Can we do something pragmatic instead, please, like adding a doc note?

-- 
http://selenic.com : development and support for Mercurial and Linux