[PLUGIN] Updated tags plugin

[John Arbash Meinel]

Erik Bågfors wrote:
> 2005/12/13, Martin Pool <mbp at sourcefrog.net>:
> 
>>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
>>
>>I'd like to make that a builtin.  Do you think you could please add some
>>tests for it?
> 
> 
> I'd love to have tags built in, but this implementation has the
> following problem
> 
> : [bagfors at zyrgelkwyt]$ ; cd a
> : [bagfors at zyrgelkwyt]$ ; bzr tags
> testtag 7
> 
> : [bagfors at zyrgelkwyt]$ ; cd ..
> : [bagfors at zyrgelkwyt]$ ; bzr branch a aa
> Branched 7 revision(s).
> 
> : [bagfors at zyrgelkwyt]$ ; cd aa
> : [bagfors at zyrgelkwyt]$ ; bzr tags
> [nothing]
> 
> This makes them kinda useless :)
> 
> But it's a good start I assume.
> 
> Regards,
> Erik
> 
> 

That specific bug is because only things which bzr knows about are ever
carried across by branch. 'bzr branch' regenerates everything.
I think we probably need to add a place for plugins to put hooks so that
their metadata can get copied across. Until now, we didn't have plugins
which stored stuff inside .bzr.
I'm not sure what the best way to do it is. We have per-revision
metadata (properties), I think we should add per-inventory metadata
(also properties, with pluggable merge algorithms, default to just copy
or conflict).
This would be some sort of per-branch properties.
I don't really know the best way to do it. I can see a few possibilities:

1) Plugins just put whatever they want into .bzr/, we add hooks in
WorkingTree and Branch so that when 'pull/copy_branch/merge' is run, the
plugins can say what they want to happen. This means that plugins put
their stuff in independent files. It means that only if you have the
plugin installed will you ever handle that information.

2) We let plugins put their data wherever they want, but they register
with another file to indicate *where* that data is. Remember, everything
has to be discoverable over an HTTP connection, so we have to put the
paths in a file. Then 'bzr branch' could at least know what files to
copy, even if it has no clue what is in them.

3) All plugins must share a single file. We just give them key/value
pairs, possibly nested. XML would work very well here, I'm not sure how
well rio would work (because it doesn't do nesting very well). Though I
guess you could have the 'value' be another rio stanza (indented). So
you get the value, and the go back to the rio parser to have it interpreted.

I don't really like #3, because some plugins will want to replace their
contents, while others should do more of an append-only. Also, when
doing a branch/pull I can see a few things could be done.
1) Only copy the contents. This would be copy & overwrite. The new value
is always the correct one.
2) Never copy. This is a local property, and should not be copied.
(.bzr/parent is one of these). Sometimes (like .bzr/parent) these are
ones where you should generate new values afterwards.
3) Merge, you want to get the new information from the remote entry, and
pull int into the local one. Something like tags would fall into this
category.

And then their are the failure scenarios. Of "I don't know what to do
with 'foo', do I fail to run, do I ignore it, do I copy it, etc".

I know the PNG format solved this by using bit-fields in their tag
names. I don't know if people know png, but basically it has a set of
tags with values. There are tags like 'tEXt', and 'DATA'. (I don't
remember the exact names or meanings). All tags are 4 characters long.
If the first letter was capitalized, that meant the tag was critical. If
you don't understand it, you don't understand the file. If the second
letter was capitalized, it meant you should copy/delete if you create a
new file based on the old one....

Again, I don't remember the specifics of what bit meant what. But it is
a good idea to define the structure so that different versions of the
software know what to do with information they don't really understand.

That would lead me to supporting #2, tags put data where they want, but
they register that information in a central location. Part of that
registration is informing the clients what they are supposed to do when
they come across it.

I would probably start with #1, because whatever we do, we need a
run-time custom behavior which plugins can define. So we put in the
hooks to allow plugins to make the behavior extra fancy. Plugins can
already override functions so that before they run, and after they are
done certain actions happen. I'm concerned that some things need to
happen in the middle of a function, with certain scope and information.
Python lets you cheat a *lot*, and it is beautiful. But it doesn't let
you do just anything.

John
=:->

PS> I would also like to see tags in bzr core. Niemeyer had an
interesting implementation, though I don't entirely agree with it. (I
didn't like having to 'commit' the tags, it made them bound at the wrong
level. They should be meta-information about revisions, not tied
underneath them. Though it did solve the merge issues.)

-------------- 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/23aa2532/attachment.pgp