tags

Jan Hudec bulb at ucw.cz
Tue Feb 21 07:55:27 GMT 2006


On Mon, Feb 20, 2006 at 08:47:37 -0600, John A Meinel wrote:
> 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

Yes, this is how I want to do the ignore-list and other properties as
well (except these will be committed along with the tree, while tags are
committed separately).

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

Well, we kind of would, but it would be wrapped in a bzr interface.
  1) The file *should not* be edited directly, ever. Because, to keep
     merge working, it *has to* be sorted (we can of course always sort
     it when committing it).
  2) It will be loooooong, but users only want to resolve conflicts.
     I believe users would most often use ui like:
       $ bzr tag --resolve
       a: foo-1-0: 2143 (revid: foo at bar.com-2345234597801)
       b: foo-1-0: 2142.5 (revid: bar at bar.com-0704203FC235)
       Which value should be used [a/b/revno]? _
  3) The changes done by tag command get committed (the file is
     versioned independently, right), but user editing it directly would
     not.
So the file will not really be directly editable.

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

I don't think it will work well for tags. When there is a conflict, it
may be a problem and the user should be notified and get a chance to
resolve it.

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

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/e68450c2/attachment.pgp 


More information about the bazaar mailing list