[RFC] BzrTagging updates

[John Arbash Meinel]

Jelmer Vernooij wrote:
> Hi,
> 
> I'm looking at updating Gustavo's patch for tags to work with current
> Bazaar. I've made some updates to the BzrTagging
> (http://bazaar-vcs.org/BzrTagging) wiki page to contain the spec of what
> I'd like to implement. 
> 
> The main two open questions are:
> 
>  * Should the tags control file be a branch or repository property ?
>  * How do we handle conflicts? 
> 
> Please comment :-)
> 
> Cheers,
> 
> Jelmer


I think the list of all tags would be in the repository, and branches
would have some sort of pointer into that. (Same way we do the rest of
our versioned history).

Conflicts should record a conflict in .bzr/checkout/conflicts. It
already is setup to record extra information about conflicts. Right now
on a text conflict it records:

path: a
type: text conflict
file_id: a-20060620140511-s8017akc56gyqbej-1

So something like:
type: tag conflict
tag name: TAG-foo

Each conflict is a 'Stanza'. So I think you can put whatever you want in
there.

At this point you have all sorts of options for how to resolve them. You
can create a TAG.CONFLICTS as suggested by Aaron.

Or you could run 'bzr tag --resolve', which could be an interactive
prompt, giving you the log output for the revisions which changed the
tags, and the difference between the two tag values. And then prompt you
for what you want to do. (Select 1, select 2, delete, update-to-current,
etc).

The 'bzr tag' command seems to be building up its own command grouping,
which IMO isn't great, but may be necessary.

I'm also concerned about the 'tag_version' property of revision ids. If
you only set it on revisions which change the tags, that means you have
to walk back your ancestry until you find a revision which has it set.
And that may not be on your left-hand side. You may never have set a tag
yourself, only merged people who set tags. Which means you would have
never had conflicts.

You could argue that at the merge point, you introduced some new tags
relative to one of the parents, so you should add the field. But you
still can have the 'tag_version' property be arbitrarily far back in
history. (You could do 1000 commits without changing any tags).

Which would mean every Revision should probably have a 'tag_version'
property. So it really shouldn't be part of the 'revision properties'.
Because it is now core information.

I think we need to be careful about how we merge the tags file.
Especially since now it is probably going to be > 1 line per tag. So we
really need a tag-specific merge algorithm, or we will get weird
conflicts. If I add a tag, and you add a tag with a similar but
different name, they may be sorted to the same place in the file, and
standard merge algorithms will cause a conflict.
This is why Aaron was talking about doing a 'scalar merge'. The idea is
just that each line/hunk/tag chunk is merged independently of all the
other ones.
We've been going with 1-line per tag, because we can get this property
with the current weave/knit merge algorithms.

John
=:->

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