Updated tags support

[Matthew D. Fuller]

On Tue, Dec 27, 2005 at 06:32:10PM -0500 I heard the voice of
Aaron Bentley, and lo! it spake thus:
> John A Meinel wrote:
> > In the short term, yes "in the Branch" is correct. I would like to
> > open it up for discussion whether tags are branch local, or could
> > be considered shared between branches.
> 
> Hmm.  Maybe we need to be very specific here, because there are two
> possible meanings of 'shared'.
> 
> 1. The current set of tags is shared among all branches

I would tend toward this, as far as possible.  I see several scenarios
to be considered here, and how I'd like them to be handled.  [Note
that when I use the term 'branch' here, I'm mostly using it as a
conceptual term a fork off a tree, rather than as a noun describing a
particular directory or object]

1) Mirroring[0].  I keep a local `bzr pull` mirror of bzr.dev.
   Releases are cut from that, and tagged RELEASE_6_0, RELEASE_6_2,
   etc.  I should have those tags in my mirror.

2) Branching[0].  I branch off that bzr.dev tree to do my own hacking
   of some sort or another.  I should have those tags that refer to
   revisions prior to that divergance point, certainly.  For tags
   referring to revisions after the divergance point, I think I should
   have them IFF the tree state they refer to exists precisely in my
   branch.  However, if I'm merging in from the upstream tree, and
   thus my revisions include as well some local changes, the tag
   shouldn't point at a revision that includes those local change;
   only if it can refer to exactly the same tree state should it exist
   in my tree.

3) Collisions.  Of course, there can be naming collisions between
   upstream tags and my local tags.  In theory, the only way this
   should happen would be if I create a tag, and then later try to
   merge from an upstream which also has a tag of the same name.  (The
   reverse case would just say "Hey, that name is already used," and
   not let me create the tag).  This probably needs user intervention
   to either ignore that upstream tag, or call it something else
   (perhaps _upstream_<upstream branch nick>_<upstream tag name> or
   something by default).




[0] I'm aware that implementation-wise, these words are meaningless as
    they just refer to the same thing.  But they're valid as terms for
    particular use cases, in terms of the way a person would use the
    tool.  The behavior stated is likewise just particular cases of
    the same behavior, so...



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