nested tree remaining questions

[John A Meinel]

Robert Collins wrote:
> So we've talked about adding this.
> 
> Is there consensus that we should add it?

Yes.

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

I think we all are in agreement on this one. (+1 from me).

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

+1 to 'revid'. I'm not as positive about .bzr-child-locations.
> 
>  * 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'	
> 

I'm not 100% sure if .bzr-child-locations needs to be versioned. While I
like versioning everything... I'm just thinking that if I move my branch
from location X to Y, then there is nothing in X, or even worse, I might
move something else into X, and then you get the wrong thing.

On the other hand, a different use case for changing the child location,
is because you want to point at a feature branch. Which having it be
versioned would be helpful.

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

I like the idea of having a fallback. +1 from me.
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/20060208/f2f3d173/attachment.pgp