Problems with deleting tags?

[Vincent Ladeuil]

>>>>> Richard Wilbur <richard.wilbur at gmail.com> writes:

    > 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

Precision, tags is really only a dict name -> revid.

The revid often embeds the committer email and a timestamp but that's not
a requirement and cannot be relied upon nor extracted from the revid.

I.e. identity and timestamp are not stored in tags file, the revid is,
and the revid is an opaque token.

<snip/>

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

Yes, because the main use case is to tag /after/ the commit, it may be
months after the commit.

The issue I have with handling the tag history as part of the branch
history is that it really is a different history than the code one.

The tags history is about the tags, whether or not I did commits on the
branch is in a different dimension ;)

If I can pull/push/merge the tag history, then propagating tags or not
become tractable.

For example:

As a dev, I will push my code commits and generally pull the tag
history.

As a release manager, I pull the code history but I push the tag one.

As a distro packager, I pull code and tags from upstream and push both
(downstream). I may also push code upstream, but never tags.

If a dev push local tags in a merge proposal, this can be fixed at
review time or ultimately fixed by the release manager.

What we have right now (including the --overwrite-tags to close the
loop) is a way to maintain a set of tags for a branch.

No history.

But no cluttered UI either and we cover all but the rare edge cases.

<snip/>

    >> On the gripping hand, it's also a crazy hard thing to retrofit into a
    >> running system for backward compatibility reasons;

Amen to that brother Matthew !

<snip/>

    > Maybe a new {tree|branch|repository} format

Well... no ;-)

Yes, tag history is nice, but not worth the cost of a migration
(including annoyed users ;)

On the other hand, we have a plugin architecture so exploring these
ideas is perfectly doable without a format change (not to mention
feature flags
http://doc.bazaar.canonical.com/bzr.dev/en/whats-new/whats-new-in-2.5.html#feature-flags
).

And that plugin could even address ckalisiak issue whereas a new bzr
won't until a windows installer is built.

That doesn't mean such a plugin couldn't be merge in core ultimately.

        Vincent