[RFC] Getting nested tree repositories into use

[Robert Collins]

On Wed, 2007-07-04 at 12:34 +1000, Martin Pool wrote:
> 
>  - It slows us down - (approximately) every time we examine a
> directory in the working tree, we dig inside it to see if it's a
> branch

Well we dig for a .bzr directory. bzr add is pretty darn fast and it
does this.

>  - People might (???) want to have a versioned empty directory, with a
> separately versioned tree inside it -- in other words to specifically
> ignore the nested-tree features in some cases.

The only use case I've heard for this so far didn't make sense. I think
it makes sense to have an *ignored* directory with a separate versioned
tree inside it though.

>  - We want to introduce them gradually to shake out bugs and make sure
> we have them right, and to have them not active unless the user wants
> them.  So we need some kind of switch - if that's not done by
> explicitly adding the reference, then we need to add an extra knob, or
> key it off the repository type, both of which seem to proliferate
> complexity.
>  - It means the behaviour of add and kind detection depend on the
> branch or repository capabilities or configuration.

I think add and other tree behaviours inherently are constrained by the
repository capabilities. You can't ask a repository to record a file
type it can't represent.

>  - If you want nested subtrees you probably need to know you want it,
> and be prepared for their special behaviour.  So it is not too much of
> a burden to explicitly add them.

The negatives on this are that its less (if at all) discoverable. 

-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/20070704/406cffe4/attachment.pgp