Support for tags

[John A Meinel]

Gustavo Niemeyer wrote:
> Greetings!
>
> I'm sad to announce that today is the last day I'm working
> full-time in bzr. On monday I'll be moving on to another
> project. I really hope to be able to keep contributing to bzr
> as time permits, though.
>
> I'd like to thank everyone for the great support in those
> three weeks, specially Robert, Aaron, and Martin.
>
> Anyway.. let's talk about the message subject a bit. :-)
>
> The attached patch implements full support for symbolic tags
> in bzr. I'll present below details about what has been done.
>
> Ah, before you start reading, if you have superpowers to
> merge that code in, *please* don't wait too long before doing
> so. This is a large patch, which probably won't apply anymore
> tomorrow. :-) There is a good number of tests for the new
> code introduced.
>
> So, here we go...
>
> - Tags are human-meaningful nicknames for given revisions.
>
> - Tags are versioned. Whenever you add or remove a tag, the
>   action is added to a "pending actions" queue, which will
>   become part of the revision at commit time.
>
> - Tag changes are merged using three-way logic. In case a
>   tag conflicts with a local change, the local change is
>   preserved and a warning message is issued.
>
> - Tags are unique inside a given branch.
>
> - Multiple tags inside a given branch may point to the same
>   revision id.
>
> - There are two new classes: Tags and PendingActions.
>
> - The Tags class manages tags in memory, and recreate the
>   text for storing them in the weave.
>
> - The tags text is a list of sorted lines with <tag>:<revision>
>   They're sorted so that weaves will delta them correctly.
>
> - The PendingActions class is a simple and generic
>   infrastructure to handle pending actions, like tag insertions
>   and removals. I'd really like to port pending merges to that
>   infrastructure once the patch gets in.
>
> - branch.pending_actions holds an instance of the PendingActions
>   class, which will create .bzr/pending-actions while there are
>   pending actions to be committed, and remove it when there are
>   none.
>
> - branch.get_revision_tags(rev_id) returns an instance of the Tags
>   class for the pristine tags in the given revision (pending
>   actions are not considered). The returned instance is
>   readonly.
>
> - branch.get_tags() returns an instance of the Tags class with
>   the current tags, which are the prstine tags for the last revision
>   plus the pending actions. Also readonly.
>
> - branch.set_tag(tag, rev_id) will add a pending action to set the
>   tag, and branch.remove_tag(tag) will add a pending action to remove
>   the tag. Both methods will do the right thing when 'tag' is already
>   mentioned in some pending action. They will also raise TagExists and
>   NoSuchTag as necessary.
>
> - There are three new commands: set-tag, remove-tag and show-tags.
>   They do what they're supposed to do. :-) In particular, show-tags
>   will also show pending actions for tags, and set-tag without a
>   -r parameter will tag the current/to-be-committed revision.
>
> - "bzr status" will show pending actions as well.
>
> Have fun! ;-)
>
>

A few comments.

One of the original discussions about tags was how to handle their
versioning. You chose to link tags with revisions, which causes a few
effects. First you have to "commit" a tag, which isn't terrible, though
you did miss this case:

bzr init
touch a; bzr add; bzr commit -m "added a"
bzr set-tag rev1
bzr diff  #Nothing output, but something changed

The problem is that you can commit a revision, whose only change was to
update a tag, but "bzr diff" won't tell you anything about that
revision. Probably just the "bzr diff" code could be updated like you
did for "bzr status"

The second problem is actually one of the originally discussed issues
with using revisions. And that is if you get an old checkout of a
branch, you can't update to the latest version of the tag. Here is a use
case:

# A user reported a bug with release 0.1.0 of the software
bzr branch -r tag:rel0.1.0 project-0.1.0
# Now I want to compare the changes versus the newer release
bzr diff -r tag:rel0.1.1
# At this revision rel0.1.1 did not exist, what happens?

Or what about a tag that existed at rev=20, but was updated at rev=30.
Maybe you are using the "stable" tag. Which keeps getting updated.

It isn't terrible. But in my head, tags should be separate from
revisions. Because they are meta-information *about* revisions. So
looking at them from a revision viewpoint is like trying to look at your
brain, difficult at best.

I think the pending-actions is quite interesting, and is a great
addition. And certainly your tags work is the best so far, and might be
the best place to start from.

I also don't understand this code:
class RevisionSpec_tag(RevisionSpec):
    prefix = 'tag:'

    def _match_on(self, branch, revs):
        revision_id = branch.get_tags()[self.spec]
        try:
            return RevisionInfo(branch, revs.index(revision_id) + 1,
                                revision_id)
        except ValueError:
            return RevisionInfo(branch, None)

If I understand it correctly, this means that if the revision_id
associated with a given tag doesn't exist, then you just return
Rev(None). Which means that if I merge you, and I do:
bzr log -r tag:OTHER

If OTHER was a tag that was in the merged branch, it should be merged
into this branch. But it won't be in the revsion-history. According to
your code, instead of getting the log of that specific tagged version, I
will get the log of all versions (and not actually including that revision).

I might be wrong, but it seems best to at least raise an error. The best
 case would be to actually pull out the log for the non revision-history
revision.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051008/435a0aab/attachment.pgp