[PLUGIN] Updated tags plugin

[John Arbash Meinel]

Wouter van Heyst wrote:
> On Tue, Dec 13, 2005 at 03:25:04PM +1100, Martin Pool wrote:
> 
>>On 12 Dec 2005, Michael Ellerman <michael at ellerman.id.au> wrote:
>>
>>>Heyaa,
>>>
>>>I've updated jrydberg's tags plugin from a few months back. It works with the 
>>>API changes since then, and I've added a few bits and pieces.
>>>
>>> * Uses the rio format to store the tags, still in .bzr/x-tags
>>> * Stores revids instead of revnos, they seem more likely to be persistent.
>>> * bzr tags prints "tag revid" instead of "revno tag".
>>> * You can delete tags
> 
> 
> How does that compare to http://people.ubuntu.com/~robertc/baz2.0/tags/?
> 
> Wouter van Heyst
> 
> 

baz2.0/tags was written by Gustavo Niemeyer. He created a weave file in
.bzr/ (I don't remember the name).
It kept a listing of tags => revision ids. Which could be updated, and
it would create a .bzr/pending-tags file.
At commit time, it would add/update any tags in the weave file.
The idea was that if you pull from a remote target, then you just get a
weave-merge on your tag file. I'm not sure how he resolved conflicts.

You can see my other email for some comments on it.

We had other possibilities, too. For example, just having a .bzrtags
akin to .bzrignore, so it was just another versioned file.

The problem is that then there is a file-id associated with it, and to
get access to the file, you have to read the inventory (to find the id),
and then go get the file's weave, etc. And you still have the problem
that it is subservient to a revision-id.

The specific problem I have, is that if I pull to update my branch, but
then revert to an older revision, the tag file now points to an old tag.
While I want to be able to revert the tag file, I don't want it
synchronized with the other files.

It isn't a major problem, and if it means the difference between having
tags, and not having them, I'm sure I would give in, and prefer to have
tags which don't fit my idea of perfection, versus not having them at all.
Also, I believe Niemeyer's changes were rather invasive, because of the
pending-tags file, and commit-time semantics. (He had to be aware of
both the tags weave, and also the current pending-tags, etc).

I'm not sure which abstraction is worth breaking. I would kind of like
to see a .bzr/tags file, which is revisioned as normal, but itself is
just a plain file like .bzrignore. But that would mean that some files
under .bzr would be versioned, and some would not. Which can be
confusing (not to mention .bzr itself would not be versioned, so they
would be a child of an un-versioned parent, though I guess the parent-id
could be something like '.bzr' which would be unique and obvious).

Having .bzr/tags would mean that the current version would be available
from remote, even without a working tree. And you wouldn't have to read
the inventory to get the id, so that you could read the weave store (for
the current version).

Actually, now I think of it. I think Niemeyer introduced a
"pending-actions" utility. Which some of those actions were
add/delete/modify tags. Which was more generic, but I don't know what
other ideas he had for pending-actions.

I do know that Niemeyer's changes were invasive enough that they won't
apply on current bzr.dev. They need to be cleaned up first. But it might
just be the best implementation we have so far.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051213/5d153ce4/attachment.pgp