tags

[John A Meinel]

Aaron Bentley wrote:
> Martin Pool wrote:
> 
> | the best way to do scalar merge of these things is likely to
> | record each scalar as a stanza, e.g.
> |
> |   tag-name: bzr-0.8-foo
> |   tag-target: mbp at fodiodisf-1230192301923
> |   placed-in: mbp at fodiodisf-1230192301923
> |
> | And you could then use the placed-in field to do resolution of merges,
> | rather than the weave annotations.
> 
> To do scalar merge, you'd need at least a 'supersedes:' field, listing
> all the previous revisions that this revision should be preferred to.  I
> think this ends up duplicating a lot of weave functionality.
> 
> Aaron

Actually, I was thinking to decouple the tag identifiers from revision
identifiers for the 'placed-in' type field.

So doing something like:

tag-name: bzr-0.8-foo
tag-target: revision at id-123123123
tag-id: tag at id-456456456
superceeds: tag at id-234234234

Yes, it re-implements the weave logic, which was why I was thinking to
have it be inside the weave information.

So instead, you would have:

i
n tag at id-234234234
1 aoeuaoeushaoeunh

i 0
n tag at id-456456456
1 aaoeuaoeuaoeuaoeu

w
{ 0
. tag-name: bzr-0.8-foo
[ 1
. tag-target: revision at id-111111111
]
}
{ 1
. tag-target: revision at id-123123123
}
W

Obviously this breaks the 1-line per tag-name issue. One interesting
solution is that weaves don't care about any character but newline. So
you could actually use a null byte to distinguish tags from their
targets. Then you end up with:


i
n tag at id-234234234
1 aoeuaoeushaoeunh

i 0
n tag at id-456456456
1 aaoeuaoeuaoeuaoeu

w
{ 0
[ 1
. bzr-0.8-foo\0revision at id-111111111
]
{ 1
. bzr-0.8-foo\0revision at id-123123123
}
W

If we keep the tag list as utf-8 sorted by tag name, then the
appropriate lines will always be replaced.

I really think having a separate tag ancestry is the way to go. We can
forbid ghosts, and with one-line per tag, we get correct performance
from weave merge. Now, this brings up a problem that we would want a
plain-text version of the tags in case of conflicts, so you would want
something like .bzr/tags next to .bzr/tags.weave
And then we are having people edit a file under .bzr, which is something
we really have been wanting to avoid.

So I'm really ending up with more of a custom rio format. We can make it
append-only, merging from someone else just adds their tags into the
file (if they aren't already there). There should only be one active
target for any given tag. And we have a unique identifier of (tag_key,
tag_id), and the simple precedence rule of "if we haven't seen that
combination before, it takes precedence".

This means there is no chance for a conflict. If I merge you, and I
haven't seen your tag before, I get your tag. But if I override your
tag, that means I've seen it, and I want a different value for the tag.
And if you merge me after I've superseded your tag, then you will get my
tag value.

The only problem is that this format is not optimized for remote
downloading (yet). But that is easy to do by adding the index file.
(Just like a knit). You don't even really need an index if you use the
rules that Robert wants to use on the indexes. But indexes would help a
little bit with atomicity. Unless you want the rio format itself to
include unique start-of-record/end-of-record characters, and a checksum.

But with an index you can detect if something hasn't been fully written
during append, and thus that record should be ignored.

I really like this design because it is simple, decoupled, and robust.
And you don't have to worry about conflicts. Just simple precedence.

John
=:->

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