Problems with deleting tags?

Richard Wilbur richard.wilbur at
Mon Apr 25 15:20:03 UTC 2016

On Wed, Apr 20, 2016 at 6:43 AM, John Meinel <john at> 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.

More information about the bazaar mailing list