Tagging idea

Martin Geisler mg at lazybytes.net
Fri Nov 6 06:09:23 CST 2009


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

Cloning this repository from tag A gives me the whole thing, including
the tag A. That is a typical confusing point for users: I just cloned at
tag X but there's no tag X in my clone?! There are also no .hgtags file.

Old revisions can be tagged by creating a new child commit at that
revision. Tagging the first revision and merging gives:

  o --- o --- o
   \         /
    `------ A

The merge is a trivial merge since no files are touched in A.

We might want to leave A as a dangling head, especially if we can close
it so that it doesn't bother us again by showing up in 'hg heads' and
warnings on push. This has some similarities with the --new-branch flag.
The goal is to warn if people push several unnamed heads to a
repository. The --new-branch flag would be a way to allow pushing new
named branch heads (which is fine since they are named). I can imagine
something similar for pushing "tag heads".


Moving tags around is interesting. If a tag is moved forward and has the
older tag as an ancestor, then it seems to make sense. We simply let the
tip-most tag dominate the others, so here 'A' refers to the right-most
changeset (revision 4):

  0     1     3     4
  o --- o --- o --- A
   \         /
    `------ A
            2

Moving A backwards can give inconsistencies. Tagging the first revision
would create revision 3 and 4:

  0     1     2   3 4
  o --- o --- A --- o
   \               /
    `------------ A

But people might pull the resulting repository in this order instead:

  0     1     3     4
  o --- o --- A --- o
   \               /
    `----- A -----'
           2

The problem is that the graph gives no clues to the ordering between the
two changesets named A.

I'm sure you get the idea... has this been suggested before? Apart from
the problem of moving tags backwards, it seems attractive. But there is
probably something we're missing :-)

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


More information about the Mercurial-devel mailing list