[RFC] proposed user doc for nested trees

[Martin Pool]

2009/5/9 Aaron Bentley <aaron at aaronbentley.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ian Clatworthy wrote:
>> Aaron Bentley wrote:
>> I struggle to see much benefit in by-value nesting (when by-reference
>> nesting is available). So I'm ok with that if others are. 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.

Can I check how these two are currently defined:

by-reference nesting: the containing tree holds basically the branch
URL and revision to be checked out under a subdirectory.

by-value nesting: the containing tree directly contains all the files
from the nested tree as if they'd been added, but pulling or merging
from branches related to the nested tree will still work?

Or is it just the difference between whether the revision of the
nested tree is updated on every containing tree commit or not?

>
> I do think it has benefits-- it is more compatible with other VCSes, and
> is simpler to use.  Bazaar has, at times, incorporated code from other
> projects (e.g. switch, the BaZing merge code, etc.), as has bzrtools.
> Sometimes you want to preserve the other project as a separate entity,
> but sometimes it makes sense to import it into your own project.
>
>>> The other major change in this document is that you talk about nested
>>> branches, not nested trees.  I find this really jarring.  Checkouts can
>>> be nested, and the branches might not be nested at all.
>>
>> I don't have a strong opinion here so I'm fine with using nested trees
>> (or nested directories) instead of nested branches.
>
> Great.  I propose reaffirming "nested trees", since that is already a
> well-known name for the feature.
>
>> The subtle point I
>> was trying to get at was that the 'structure' exists in the branch and
>> is there in a treeless branch say, i.e. it doesn't require a 'working
>> tree' to be meaningful. (In comparison, filtered views really are
>> working-tree local data.)
>
> There is metadata at all three levels: branches, repositories and
> working trees.  The goal of the feature is not to nest the branches, it
> is to nest the WorkingTrees and RevisionTrees.
>
>> If I get permission to change checkouts as Mark has requested, all
>> checkouts will be lightweight and heavyweight checkouts will be created
>> via branch --bind, so "nested branch" would not be ambiguous/misleading
>> as it could be now. See http://bazaar-vcs.org/DraftSpecs/SimpleCheckouts.
>
> I still disagree.  There should be no branches at all in the working
> tree, so they won't be nested.

What do you mean?  That in the SimpleCheckouts spec the branch is not
colocated with the working tree?

-- 
Martin <http://launchpad.net/~mbp/>