Tagging idea

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Fri, 2009-11-06 at 13:09 +0100, Martin Geisler wrote:
>> Hi guys,
>> 
>> I talked with a colleague today (please keep him in CC) and explained
>> to him how our tags work. Being a computer scientist, he had no
>> problem seeing the advantages and disadvantages of having them in a
>> version controlled file.
>> 
>> But we talked some more, and came up with an idea: instead of letting
>> tags *point* to revisions, we can let tags *be* revisions.
>> 
>> What we mean by this is that a tag is a commit. So given
>> 
>>   o --- o
>> 
>> I can make a tag A by making a new commit with extra['tag'] = 'A':
>> 
>>   o --- o --- A
>
> So what revision do you get when you check out the tag? If your answer
> is "A's parent", then you're more or less in the same place we are
> now: A is a pointer. If your answer is "A itself", then what does "hg
> log -r A" show? The obvious answer seems to be "this is an otherwise
> empty tag changeset".

Yes, you get the tag changeset.

> Which is fine in itself, but causes other problems. See here:
>
> http://markmail.org/thread/23tmst7rxuoysh4a

Ehm, that links to a thread discussing a Gnome DVCS survey?

> Your solution is basically (a) make tags part of a changeset. This
> gives us difficulties with deleting, changing, and merging tags
> because changesets are immutable (which are all natural properties of
> the current scheme),

I was surprised myself to see how easy it is to get merge conflicts in
the .hgtags file. You can basically not add different tags on different
branches without getting a merge conflict since we use no special merge
program for .hgtags.

I really like that the current scheme makes it easy to understand how
these conflicts should be resolved (simple and predictable). But it's a
shame that they appear in the first place.

The proposed scheme makes it easy to move tags forward, which I assume
is the typical case. Moving tags backwards seem more difficult. But what
if a tag commit could include an explicit reference to the tag it is
superseding (if any)?

The case where several people tag different changesets with the same
name would still have to be handled -- I imagine you could get a warning
on 'hg pull' saying that tag "A" refers to several changesets. To
resolve this conflict, one could re-tag the right changeset with tag "A"
and include information saying that the new tag is superseding the two
conflicting tags.


In some sense, I think the proposed scheme encoded the updates of
.hgtags in the changeset graph directly:

* instead of adding a line to .hgtags (and making a commit) when a new
  tag is created we just make a commit saying so.

* instead of adding a nullid line to .hgtags (and making a commit) when
  a tag is deleted we make a new commit saying so.

It's of course just a hunch so far :-)

> nevermind interesting issues with extra heads, which are easily just
> as confusing as the pull -r problem, but harder to avoid.

If an old changeset is tagged, then I was going to propose that the new
head is merged into the current parent right away. It will always be a
trivial merge. If you pull the tag you wont get the merge changeset, but
that appears to be what you want in that situation.

> What's probably called for here is a doc fix for "hg pull" warning
> people about pulling tags. We've actually now got a fix for the most
> common use case: hg pull --updaterev <tag>.

That is of course a good idea :-)

-- 
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/0ce86a80/attachment.pgp