[RFC] proposed user doc for nested trees
ian.clatworthy at internode.on.net
Sat May 9 00:34:50 BST 2009
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
> 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
> 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
More information about the bazaar