Problems with deleting tags?

Matthew D. Fuller fullermd at
Mon Apr 18 09:20:20 UTC 2016

On Sat, Apr 16, 2016 at 09:33:27AM -0600 I heard the voice of
Richard Wilbur, and lo! it spake thus:
> My understanding of tags is probably incomplete but it at least
> connotes creating a name for a snapshot of version information.
> What would it mean to make tags version controlled?  Would you be
> able to revise the version information associated with a tag and
> have a history for the version information associated with each tag?

It happens that this is a topic I've dribbled some skullsweat onto in
the past.

It's not just a question of "being able to tell when a tag was moved",
or similar things.  Being able to tell "when" (in an abstract sense) a
tag was _made_ and never changed is necessary to do much resolution of
anything.  Without history, you're limited to a 2-way comparison of
tags between sides, and the only difference you can possibly resolve
safely is one side having a tag the other lacks, and the only safe
resolution of that is to assume it's a new tag that should be
propagated.  And that resolution will be wrong sometimes (like, in the
OP here).

It means the only way to delete a tag is by coordinating with
everybody with a related branch, since there's no way to distinguish
the case "branch A has added a new tag since branch B last synced"
from "branch B has deleted a tag it got from branch A".  Without even
considering the case of wanting to _move_ a tag, or do any human- or
business-level introspection into "who added this and when".

Now, AFAIK, Mercurial with its .hgtags is the only major system that
implements such a thing (I discount the if-you-squint-real-hard
pseudo-implementation of something vaguely related in svn, because...
well, svn).  And that has [at least] two bits of bizarritude
associated with it.  Because it's a file you commit with the revision
identifier, you can't add to it 'till you know the revision
identifier, so you have to add it after the fact, which leaves you
with the wacky proposition that in any tagged revision, you don't know
about the tag on yourself.  And there's the creepy layering inversion
that you have to pull something out of a revision to figure out which
revision you're looking for.

Now, on the plus side, I also think it's OK if the UI for conflict
resolution sucks, because I think that with versioning to handle the
Obviously Correct cases, conflicts should be almost nonexistent.  We
have ugliness now trying to delete, and history would make that Just
Work.  We have _super_ ugliness if you try and _move_ a tag, and
history would make that Just Work.  You'd only get a conflict if
you've got two sides that both try to alter a tag at the same time.
And depending on your perspective, that's either the user misusing
tags (in which case the user needs to be fixed, possibly by adding
another feature to handle the use-case that's actually desired), or
the developers completely misapprehending what tags are for (in which
case the whole thing needs to be re-envisaged anyway).  And I tend
toward the former, on the thought that this is a step-back of the svn
problem; if you actually get real conflicts more than blue-moonly,
you're not having problems with your tags-the-Platonic-ideal, you're
having problems with your not-really-tags-but-it's-the-closest-
feature-in-my-VCS-to-what-I-really-want.  Which I think is far better
as a separate mechanism, and that trying instead of overgeneralize and
stretch tags to cover both is a bigger mess.

On the gripping hand, it's also a crazy hard thing to retrofit into a
running system for backward compatibility reasons; doing it in any
sort of right-ish vicinity would need a flag day (or long enough
advance anticipation of such a thing that you could be assured of no
corrupting and few enough refusing old versions in the wild).  So, in
a way, any extant system doesn't need to worry in the slightest about
the various tricksinesses in feature boundaries.  Yay.

Matthew Fuller     (MF4839)   |  fullermd at
Systems/Network Administrator |
           On the Internet, nobody can hear you scream.

More information about the bazaar mailing list