Problems with deleting tags?

[Richard Wilbur]

On Wed, Apr 20, 2016 at 6:43 AM, John Meinel <john at arbash-meinel.com> wrote:
> We discussed it a lot, I think the main reason we didn't do it was the
> conceptual overhead of yet another thing to think about.

I think I'm starting to understand what you mean here.

> My personal feeling
> is there are 2 fairly lightweight ways of versioning tags:
>
> Create a version history that is completely independent of all the branch
> revision ids. Its just a sorted list of tags that is a versioned file, but
> versioned outside the history of the branch itself. This lets you do
> interesting merging, without getting into the HG problem (and you can create
> a tag as part of commit, etc).

I see how that gets around the Hg problem but an interesting issue
that comes to mind is:  if the tags are versioned separately, how do
you refer to the meaning of a tag at some previous revision in the
source tree?  Do you look up that revision in the source tree, find
the date/time stamp, then look up the meaning of the tag at that date
and time in the tag file version history?  (This seems important
because of our '-r <revisionid>' syntax for many commands which refers
to the source revision history the users deal with, but in this case,
not directly to the tag revision history.)

>From what some folks are mentioning, tagging a revision doesn't
usually happen in the process of creating the revision; often quite a
while later.  So, while it is great that we could do it, adding the
--tag option to bzr commit still seems like a feature we don't need.

> Just record what you are superseding. So you'd have something like a tuple
> of (tag-name, branch-revision-id, old-revision-id). This doesn't give you
> full ancestry merging, but you can do deletes and tell when a tag is
> changing slowly who wins. Because ("my-tip", None, "branch-x2bfu") is a
> delete, and ("my-tip", "branch-x2bfu", None) is a create, and the former
> clearly supersedes the latter, and ("my-tip", "branch-zzdon",
> "branch-x2bfu") is a conflict with the first one (2 people changed) but not
> with the second.

This certainly seems a lot more light-weight, but still requires us to
change the tag file format.

> Ideally you'd have a custom merge algorithm for whatever versioning you use,
> because things like 2 people introducing similarly named tags isn't a
> conflict, while 2 people editing lines that touch eachother generally needs
> to be resolved.

I agree we need a custom merge algorithm to encode the behaviour we
desire because it is simpler than with normal source files.

[...]

> So you certainly could do
> "just-another-versioned-file" like .bzrtags, but I think the lifetime of
> tags is outside the branch. (If I bzr co -r tag:REALLY_OLD, it feels like I
> should still be able to bzr update -r tag:SOMETHING_NEWER, which
> tags-in-the-source-tree don't give you.)

That's why you put the branch name in the tag definition, above?  So,
with that setup, when you push, pull, or merge a branch you would only
consider the subset of tags with that branch name?

Thanks, John, for sharing history from past discussions and some
architectual alternatives.