Problems with deleting tags?
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
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.)
On Wed, Apr 20, 2016 at 9:26 AM, Matthew D. Fuller <fullermd at over-yonder.net
> 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...
More information about the bazaar