Problems with deleting tags?

John Meinel john at arbash-meinel.com
Wed Apr 20 12:43:11 UTC 2016


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. My personal
feeling is there are 2 fairly lightweight ways of versioning tags:

   1. 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).
   2. 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.

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.

(2) only gives you 1 bit of history, which makes it hard if a tag is
changing a lot on one side and then you merge, you can only throw a
conflict. (a => b => c, but I only know about a, and I can't tell that C
supersedes B which also supersedes A). Tags change slowly enough it is
likely not a concern and can make (2) effectively as good as (1) with a lot
less overhead.

hg does have some tricks to support referencing the
commit-that-is-in-progress. Namely they use the offset in the index (they
know they have 5 items, so the next commit is clearly going to be the 6th
offset). Bazaar using arbitrary revision-ids allows us to create the
revision-id before the commit is finalized, which lets us just reference
it. (Git and Mercurial use a sha of the content, so can't reference the
content until it is all finalized.) 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.)

John
=:->


On Wed, Apr 20, 2016 at 9:26 AM, Matthew D. Fuller <fullermd at over-yonder.net
> wrote:

> Meant to add, but got lost in the torrent:
>
> >   So, for the VCS-tag vs. local-tag, it may be reasonable to have the
> >   same backend code (maybe slightly different to maintain disjoint
> >   lists, or maybe an extra flag in the data structure saying which
> >   it's on) and just different commands or flags for them.  Though that
> >   can intersect oddly with some questions of how the history is
> >   represented too as far as how it gets publicized, so maybe it's not
> >   quite so simple.
>
> And for that matter, the main point of versioning on tags isn't so
> much "let me see the history of this" as "automate resolution of
> changes on merge", so versioning is almost a waste for local tags,
> since sorta by definition there's nowhere you'd want to merge them.
>
>
> --
> Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
>            On the Internet, nobody can hear you scream.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20160420/1cc807ac/attachment.html>


More information about the bazaar mailing list