Tags fix proposal
Matt Mackall
mpm at selenic.com
Mon Jan 12 03:15:36 UTC 2009
On Sun, 2009-01-11 at 21:01 -0500, Sean Russell wrote:
> Giorgos Keramidas wrote:
> > On Sun, 11 Jan 2009 18:53:48 +0100, Mathieu Clabaut wrote:
> >
> >> On Sun, Jan 11, 2009 at 1:50 PM, Hans Meine wrote:
> >>
> >>> AFAICS, one of the main "glitches" people report about hg tags is
> >>> that "clone -r foo" does not contain the tag foo. I wonder if this
> >>>
> ...
> > hg clone -r tagname source-repo destination-repo
> >
> > and then being unable to see the tag with:
> >
> > hg -R destination-repo tags | fgrep tagname
> >
> > or even seeing the *wrong* changeset (because the tag was overruled and
> > there is an 'old' changeset with this tag in the destination repository.
> >
> This is, to me, the most worrisome aspect of Mercurial tagging: tagging
> in Mercurial isn't idempotent.
>
> hg clone -r tagname A B
> hg clone -r tagname B C
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.
In other words, there are inherent trade-offs to each approach. Whatever
method we could have chosen would have had downsides to complain about.
And I'm quite convinced I chose the best of the possible alternatives.
The right fix for the clone -r <tag> problem is: don't do it. The only
advertised uses for clone -r are:
a) pulling single branches
b) safely eliminating unwanted changesets
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list