[RFC] BzrTagging updates

[Matthew D. Fuller]

On Tue, Jun 20, 2006 at 12:15:10PM +0200 I heard the voice of
Jelmer Vernooij, and lo! it spake thus:
> 
>  * Should the tags control file be a branch or repository property ?

I would think they should certainly be a branch property.  To take the
standard tack, I can certainly have RELEASE_1 on two different
branches in the same repository, and the two have no relation
whatsoever to each other.  Too, when I drag a branch out of a
repository, it should take its tags with it, not suddenly lose them.

I also very heavily favor type 2 or 0 over type 1; it just doesn't
seem like tags 'belong' in that flow.


>  * How do we handle conflicts? 

I think it's best to do it via renaming them.

(This is dashed out pretty quick&dirty, because I'm too tired to do it
cleanly, but I think it elaborates well from this rather sketchy run.
I'm ignoring the how/should we store history of changes to a tag here;
that's orthogonal.)

A tag is identified by a tag-id, which is autogenerated and globally
unique (the counterpart of a file-id, roughly).  The tag name
(whatever the person calls it) is an alias to that tag-id.  The tag
then refers to a revision-id.

When you take from another branch, via branch/pull/merge/etc, you take
tags you don't already have and jam them onto your branch.  If an
incoming tag name conflicts with an existing tag name on your branch,
the incoming is renamed to <something>[0].  If you already have a tag
with that tag-id, the tag name is never taken from the other branch.

If you have that tag-id, and it's pointing to a different revision,
move it (and/or use some history-checking smarts to determine if it's
gotten a new value you should move it to, or it it's the old value you
moved away from).

To go with this, renaming tags should be a nonexistent operation in
the UI, aside from that internal collision-avoidance renaming and
renames of already interally-renamed tags to make the auto-generated
'unique' name more suitable for your circumstances.  This avoids any
sort of issues with different merge directions and 'intentional'
renames.  If you want to change a tag name, create a new one.  The
case where this fails is:

- Bob creates a branch and a tag on it
- Sue branches it and moves the tag to some other rev
- Bob renames the tag (that is, deletes and re-adds)
- Sue now has the 'renamed' (but presumably still logically equivalent
  within the branch) tag, but pointing to the old rev Bob had it on
  rather than the new rev she likes it it.

I think this is a sufficiently rare scenario that it's the bullet to
bite here.  Other allowable behavior creates similar problems in, I
think, more common situations.

The remaining question is what to do with a tag deleted from an
upstream[1][2] when you merge.  I think it should go ahead and delete
from yours as well.  The UI should list any tags renamed or deleted in
the process of these pull/merges, giving you a change to notice/alter
them.



[0] Prefixed with something like _upstreamnick_ is a reasonable choie,
    with perhaps some numeric fallbacks for collisions.  REL_1 becomes
    _bzr.dev_REL_1, or _bzr.dev_2_REL_1, etc.

[1] For "upstream", feel free to read "downstream, that I'm merging
    somebody's changes from".

[2] Note that this case pretty much requires type 2 rather than 0,
    since otherwise you can't distinguish "deleted from upstream" from
    "never in upstream, always local".  So, yeah, I guess we really do
    need history of 'em.


-- 
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.