Problems with deleting tags?

[Richard Wilbur]

On Tue, Apr 19, 2016 at 12:20 PM, Richard Wilbur
<richard.wilbur at gmail.com> wrote:
> On Mon, Apr 18, 2016 at 12:45 AM, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
>> There is http://wiki.bazaar.canonical.com/Specs/Tagging which summarized
>> some discussions, the mailing list archive may contain more.
>
> Thanks for the link.  I read it and
got interrupted before I finished my comment.;>)

The idea of `bzr commit --tag:<tag name>` being an atomic operation
which creates the tag during the commit seems desirable if you desire
the tag to be visible in the tagged revision (the revision the tag
refers to also contains the tag).  Otherwise, it seems like a lot of
effort for no good reason because it doesn't fit our normal file
version control paradigm that a file's contents are known before the
commit commences and unchanged by it.

Oddly enough the second sub-section of the "Introduction" says,

--------------------------------------------
Behaviour of tags

Tags are ''versioned'': it's possible to see when a tag was placed,
and by whom. If a tag is later moved or deleted, that's also recorded.

Tags are defined by revisions; the current tags for a branch are those
of the branch's tip revision.
--------------------------------------------

This is listed on launchpad as an implemented "blueprint" for bzr
v0.15 so either I incompletely understand the idea of blueprints or
we've lost some functionality since bzr v0.15.

Several of the "features" mentioned don't seem to exist today, e.g.
`bzr log --tag <tag name>`.

Interesting discussion between subsequent paragraphs.  The
"Alternative Mechanisms" section looks like an outgrowth of
implementation discussions:

--------------------------------------------
[type 0] Tags are not versioned (ie once they are changed, you can't
see the previous value.)

This is OK for some uses, but is insufficient because it loses
historical data, and because tags can't propagate into mirrors without
a special mechanism.

[type 1] Tags are versioned in the same timeline as revisions.
(Changing tags requires creating a new revision, possibly implicitly.)

[type 2] Tags are versioned in a different timeline from revisions.

[type 3] There is no tagging mechanism; we just suggest to use branches instead.
--------------------------------------------

Regardless of the objection voiced, it looks like the implementation
we have is "type 0" (unversioned).  It seems to me the simplest
implementation, and what some are advocating recently, would be "type
1" (versioned in same timeline as revisions).

In order to be able to perform research on the history of a tag, it
seems we should implement something like `bzr log --tag <tag name>` to
return log entries where the tag <tag name> is created, modified, or
deleted.

Thanks again Vincent for the link.