Counterintuitive tag behaviour (broken design?)

[Matt Mackall]

On Wed, Mar 14, 2007 at 06:45:14PM +0100, Johan Herland wrote:
> The above analysis makes me want to look closer at how the system would 
> work if we disallowed branches on .hgtags. First, I must say that 
> disallowing branches on a file in the repository that is otherwise much 
> treated as a regular file, sounds like an ugly hack, and I do not 
> pretend to know the technical difficulties involved in making this 
> work.

The first obstacle is probably insurmountable: the nature of a
distributed system means that different clients -will- diverge. There
is no possible mechanism to keep disconnected peers from making
local changes to the tags.

> > Ok, what does this tell us about the design? First, points (f) and
> > (c) basically says tags must be version controlled. And this
> > basically means it must happen exactly in parallel with the project's
> > DAG. Keeping the tag data in .hgtags meets those requirements with
> > the added benefit of not adding a second namespace. Also, (b) falls
> > nicely out of this, though the actually merging could be friendlier.
> 
> I agree that tags MUST be version controlled, but I don't think they 
> should be branchable. Branchable tags directly violates (i).

You wrote:

> i) Tags are global (to the repository). I.e. the result of "hg tags" and
>    "hg up -C <tag>", etc. must be independent of the current working
>    copy. This concept has been referred to as the "global tag context"
>    in this discussion.

At no point does 'hg tags' reference the .hgtags file sitting in the
working directory.
 
> j) If two users independently create a tag "foo" pointing to different
>    changesets in their respective repositories, merging the two
>    repositories MUST result in a conflict that cannot be _automatically_
>    resolved. This is a feature.

Why?

For a tag like "the-official-1.0-release", if this happens, it's user
error. Not our problem. Yes, there's a potential for someone to do
something malicious here, but if you're pulling code from people you
can't trust without reviewing it, tags are the very least of your
problems.

For a tag like "the-latest-build-that-actually-works", if this
happens, it's a don't-care. Tags on both branches are equally valid
unless one obsoletes the other. Using the most recently committed or
pulled version of the tag (aka tip-most) is -the right thing to do-.

--
Mathematics is the supreme nostalgia of our time.