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