Updated tags support

[John A Meinel]

Johan Rydberg wrote:
> "Matthew D. Fuller" <fullermd at over-yonder.net> writes:
> 
>>>> 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 guess that you want tags to be shared between all _related_
> branches?  After splitting the (working-dir, branch, repo) tuple,
> several unrelated branches may populate the same repo.
> 
> Another issue; should a tag always be available in the revision it
> points out?  In other words; should tag FOO, that is a symbolic name
> for revision BAR, be present after a "bzr branch -r FOO foo"?
> 
>>From my point of view, the obvious answer is "yes".  But it is far
> from obvious when it comes to the implementation.  (I have to verify
> this but) I think suggested implementation makes tags present from the
> revision that introduced the tag, not the revision the tag points to.
> Take the following example:
> 
>    (hack/commit * N)
>    $ bzr revno
>    25
>    $ bzr set-tag -r 10 foo-tag 
>    $ bzr commit -m "set foo-tag"
>    $ bzr branch . -r tag:foo-tag bar
> 
> Should 'bar' know about foo-tag?
> 
> ~j
> 

That is my specific problem with Niemeyer's implementation. Tags are now
subservient to revision ids, even though they are meta-information
*about* revision ids.

I would rather see tags independently revisioned. So set-tag,
remove-tag, etc would create a new unique identifier in tags.weave, with
its own ancestry separate from the branch's ancestry.

Here is a mockup:

.bzr/tags # Current tags
.bzr/tags.weave # Ancestry of tags

bzr set-tag # Updates .bzr/tags
bzr show # Prints out the list in .bzr/tags
bzr show -r something # Prints out the history of tags.weave

Now, the only problem with this setup is we now have a 'tags' file which
is the working set of tags, which needs to be saved to the weave.
We could use something like:
bzr commit-tags
To just commit the tag changes. Optionally, 'bzr commit' could also
check to see if the tag file needs to be committed.

Another possibility is that we only have:
.bzr/tags.weave

And the current set of tags is just the last version stored there. The
only reason to have versioning is so that if someone deletes a tag, or
changes a tag (or we merge a tag we don't want) we have a way of
undo-ing the action.

If we go with this route, than any 'set-tag' or 'unset-tag' is
effectively a new commit to the .bzr/tags.weave file.

By decoupling the tag revision identifiers from the branch revision
identifiers it becomes more obvious that all tags in the latest tag
version are visible, independent of the branch version.

In this situation, we still need to deal with tag conflicts. We can
merge tag.weave files, and create a new version if we want to.

Also, it might be nice if the tags file would only reference revisions
which exist in the local repository. But it may not be required.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051228/6b2d3b45/attachment.pgp