what should be done to merge nested trees patch to bzr-core?

[Martin Pool]

So, historically, it was partly blocked because we had a bad review
process that was too slow and too much blocking things coming in.

To get it in now, let's talk instead about requirements:

 * I don't think it has to start in a plugin, but it should start in a
way that minimizes the risk of bugs biting people who aren't using the
feature.
 * It shouldn't cause format bump pain
 * It shouldn't make performance worse when trees aren't used, and the
speed impact when nested trees are used should be proportional to
what's reasonable.  For instance I think a previous patch scanned the
whole tree when you locked or unlocked it, and then locked every
subtree; this is an unacceptable performance impact.  The current code
doesn't seem to do that (at a brief glance) but the comments say it
does, so I don't know.
 * Adding one nested tree under your current tree shouldn't cause
other things to change in surprising ways.
 * A patch that needs to touch all over the codebase seems risky, and
seems like things ought to be refactored more before its introduction.
 * There should be a path to letting people specify that the subtree
points to a particular revision, or to the tip of a branch (or a tag.)
 * You ought to be able per command to either choose to descend into
subtrees or not.

The current code has the approach of saying the overall tree with its
nested components basically acts like a single tree.  I'm not
necessarily against that but I'm not sure it matches what people want
to do with this.  People mostly talk about wanting to have dependency
libraries present, or documentation, in subtrees.  Is just assembling
multiple checkouts enough?  Do they really want to default to
committing in the parent tree implicitly committing the subtrees, and
similarly for diff?  It seems at least they would want an option not
to descend, and perhaps it's safer to start with that as the default?
Perhaps this is just as simple as having one class that represents the
composite, and another the single tree, and then opening one or the
other.  What did you learn from scmproj etc?

Perhaps other people can add other requirements or disagree with some
of the above.  If we settle this then we will have clear grounds to
assess and improve a patch and then bring it in.
Martin