Tagging idea

[Wagner Bruna]

Hello,

Martin Geisler wrote:
> 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.

I've played a bit with this idea (thanks to a friend of mine trying to 
understand why tags are so different than named branches...).

> 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

You'd probably want to allow many tags per revision, so the extra field could 
hold a list instead. And maybe a list of deleted tags too (but see below).

(...)

> 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.

One way to solve that could be:

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

But this approach would lose the revision <-> tag identity (although for many 
users only the revision contents would matter).

IIRC this is the main problem that the .hgtags mechanism solve. Of course, if 
the named-branch-like tags would be supported *in addition to* .hgtags, you 
could simply use .hgtags to solve conflicts, delete old tags, etc; in your 
example, the revision 4 would make .hgtags point to 2, for instance (solving 
tags this way could even be a condition for committing the merge).

++t;
Wagner

> 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 :-)