nested tree remaining questions

[Jan Hudec]

On Wed, Feb 08, 2006 at 12:39:55 +1100, Robert Collins wrote:
> 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.

It sounds reasonable to me. +1, though I am not a core developer, so it
does not have the weight.

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

It was basically agreed upon (unless I completely misunderstood things)
that .bzrignore should be replaced by bzr versioned data. Than we'd get
no control files, so adding them does not sound a good idea. Yes,
child-locations should be versioned data, so +1.

I'll go a bit further. I am currently thinking about creating a
reasonably generic api for adding versioned properties to inventory
entries. These will be useful for the ignore list, line-ending and
charset conversion and keyword expansion, tracking execute flag (which
currently needs special treatment in quite many places in the code) and
possibly other things. So the child-locations could be a property of
the subtree node.

I don't want to make this completely generic the way subversion does.
Each property would have to be defined in the code. Only instead of
InventoryEntry having special attribute for each property, it would have
a dict of them. Each of them would be an object, that would know how to
compare, merge and apply itself.

Though, someone could easily make a plugin to support generic
attributes, but I don't consider them a good idea.

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

+1. No matter how will be stored, the user interface would be along the
lines

bzr subtree-url [--add|--delete|--edit|--list] path/to/subtree some://url

(And the options would be along the lines of what is outlined at
http://bazaar.canonical.com/NewIgnoreRulesSpec - perhaps even with the
-D on path/to/subtree - than it could set URL for . in tree containing
it when no path given)

-- 
						 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/20060208/bdefa892/attachment.pgp