nested tree remaining questions

Robert Collins robertc at robertcollins.net
Wed Feb 8 01:39:55 GMT 2006


So we've talked about adding this.

Is there consensus that we should add it?

What should it look like and what should it record?

I think it should not subclass DirectoryEntry as its a terminal node as
far as the tree is concerned.

Open discussion points AFAIK:
 * what id should the node for the nested tree have in the parent. I
think it should be the root id of the child tree. Seeking +1 or
discussion on this.

 * what data should be 'in' the node? At UBZ we discussed just the revid
of the revision present when we committed. I think that this is fine and
suitable - we proposed a hinting mechanism for finding that revision and
that root id to reproduce the tree called '.bzr-child-locations'.
Seeking a +1 on the 'content is the revision id of the child' to
finalise this.

 * What should .bzr-child-locations look like. At UBZ it was a control
file in the source tree. I think now that its better to have it as bzr
managed data - add a 'bzr edit-child-locations' command to show it to
the user, but not pollute their tree with [and incidentally allow us to
extend the format in the future]. Seeking a +1 on '.bzr-child-locations
is versioned data'	

 * What child location data do we need? I think all we need is
rootid:url pairs. We can of course try all the urls, but the root id is
a nice hint. multiple entries per url and per rootid are allowed, to
give fallback facilities and the like. Seeking a +1 on this.

Rob


   
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060208/44978e73/attachment.pgp 


More information about the bazaar mailing list