Problems with deleting tags?

[Richard Wilbur]

On Mon, Apr 18, 2016 at 3:20 AM, Matthew D. Fuller
<fullermd at over-yonder.net> wrote:
> It happens that this is a topic I've dribbled some skullsweat onto in
> the past.

Matthew, thanks for sharing it with us, now.

You make some pretty strong arguments in favor of version-controlled
tags.  Interestingly, as of bzr 2.7.0, the identity and date/time of
the tag creator is stored in .bzr/branch/tags but `bzr tags --verbose`
doesn't even display that info.  So right now it looks like you have
to resort to peeking into .bzr/branch/tags in order to determine "who
added this and when".  (This seems like an obvious feature which is
missing--read "bug".)

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

It looks like making the tag creation an integral part of the commit
operation was proposed but, as far as I can tell, left unimplemented
in bzr.  Otherwise we are left with the same situation:  the tag
appears in the tree after the revision to which the tag refers.  I
guess that makes it important to consult `bzr log .bzr/branch/tags`
(once we have version-controlled tags) to find out at what revision id
the tree contains the desired tag.

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

That would be an outgrowth of having the tags under normal version
control.  What type of version control would you propose that would
avoid this situation?  As long as the tag hasn't been deleted, the
most up-to-date version of the tag would be available in the current
revision of the .bzr/branch/tags file.

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

That's comforting from the standpoint of someone looking at the
feasibility of implementation.

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

So how would you characterize this use case where the user misuses
tags and where you suggest fixing the user by possibly "adding another
feature to the handle the use-case that's actually desired"?  (In
other words, what feature is needed to fix the user?  Possibly "local"
or "personal" tags?)

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

Maybe a new {tree|branch|repository} format (first supported in bzr
2.8.0?) would suffice which would allow us to recognize during a merge
that we need to try to bridge the gap.  bzr 2.8.0 would include code
in `bzr upgrade` to bring old {trees|branches|repositories} up to the
new format.  The only burning question remaining would be how to
interact with bzr v<2.8.0.  I suppose we could treat the old tags with
a little less credence than a new format tags file when presented with
both and treat all the old tags as "local" by default.  Then the user
could specifically promote the tags she desires to "global" status.