tags

Martin Pool mbp at sourcefrog.net
Tue Feb 21 06:21:16 GMT 2006


On Mon, 2006-02-20 at 08:47 -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.

You could still use the weave graph to get ancestry information, but
you're right, it is a bit of a coupling problem.

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

You're talking about this append-only rio-like format instead of it
being in a weave file?

> 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 think it is conceptually possible to have conflicts: if two people
both try to make a "release-0.8" tag on related branches then they have
a disagreement and in some way that needs to be resolved.  This approach
is like using a resolution strategy of "default to the other guy's
value", which is perhaps reasonable -- I would like to avoid needing to
show conflict markers on tags, which could be confusing.  There should
probably be at least a message indicating that your tags got changed.

After thinking more about it and talking with Robert I agree that
versioning tags separately from revisions will probably be nicer, so
there won't be any commit operation to store them, and you can see the
most recent versions even if you branch from an older one.

-- 
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/a8c3e199/attachment.pgp 


More information about the bazaar mailing list