Support for tags

[Gustavo Niemeyer]

> 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

Yep.. something similar to the x-bit handling should be used.

[...]
> 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:
[...]
> 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.

That was my original idea, but Robert and Aaron belive that being
able to merge tags is something important, so I moved to the
implemented approach.

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

Thanks. Unfortunately I won't have much time to fiddle with that in
the near future, so I really hope you come up with something
acceptable out of it.

> I also don't understand this code:
> class RevisionSpec_tag(RevisionSpec):
[...]

That was a copy & paste from the current revid: handling. Since
tags are really nicknames for revision ids, I thought that it'd
be correct that way. If it's not, perhaps the revid: handling
should be reviewed as well.

-- 
Gustavo Niemeyer
http://niemeyer.net