[RFC] proposed user doc for nested trees

[Ian Clatworthy]

Aaron Bentley wrote:
> Ian Clatworthy wrote:
>> Am I missing
>> some magic benefit re by-value nesting?
> 
> by-value nesting is available now and works now, either using bzr join
> or the merge-into plugin.  I realize that you're not suggesting we
> disable by-value nesting.  We would simply stop calling it nesting.

I'd prefer that. I guess I just never thought of "joining/importing" a
project into another as "nesting", given it no longer has a separate
identify inside the new project once it's incorporated.

IIUIC, "works now" applies only to projects using a non-chk rich-root
format, yes? (WorkingTree.subsume() looks like it needs tweaks to
support CHKInventories.)

> Great.  I propose reaffirming "nested trees", since that is already a
> well-known name for the feature.

Sure. I'll update the doc on the next round accordingly.

>> The file mask/map also need to be stored in the inventory
>> IMO (which implies yet another repo format unless something like
>> "inventory item properties" are supported as suggested in
>> http://bazaar-vcs.org/DraftSpecs/ExtensibleMetadata).
> 
> I didn't think you were proposing that we add such a thing right now.  I
> thought that was a future work/wishlist kind of thing.

Right. For now, I just want us to consider it during design so whatever
we do doesn't prevent us from adding it later.

>> If the library is no longer used, what value is there is keeping a copy
>> of the nested branch on disk?
> 
> Being able to access old revisions.

But that still ought to be possible without the tree there, yes? I
really suspect most users will run 'bzr rm' instead of 'bzr rm --keep'
so if that's bad on a nested tree, we better error out unless they add
--force say.

Ian C.