nested trees design-approach : composite trees vs iter_changes

[Martin Pool]

For those following along at home, the underlying design is described in

 http://bazaar-vcs.org/NestedTreesDesign
 http://bazaar-vcs.org/NestedTreeSupport

Is there something else I've missed.

I see Aaron was editing the design document up til April.  I'm not
sure if it's totally up to date with that document.

I would have liked to see this patch include a description of
CompositeTrees to go into the developer guide or overview for a couple
of reasons.  Firstly, if it's going to be a major new concept
documenting it will help people coming into the bzr code later on to
understand it.  Secondly and more importantly here, it'll let us
discuss the conceptual side of the patch at a higher level than the
code, knowing the documentation is in sync with what's coming in
through the patch.

For instance, that document says

 > The root-ids of trees must be unique, so that the same file-id can
be used in both the containing tree and the subtree, to simplify
access within trees.

which seems to be at odds with this thread saying that common file-ids
aren't allowed across trees.  I don't mean to beat up on that document
or its author/s and maybe the point didn't seem important before, but
it does seem like something better handled in documentation than in
patches.

The thing we've done a while ago with people proposing merges into
doc/developers/ is a bit like an Enhancement Proposal idea, and I
think it really does keep the discussion at a higher level.  Of course
the design may change, or people may notice problems, only during
implementation.

I think Vincent has a reasonable point that you might expect to be
able to add two nested trees that have common history therefore common
file ids, and that it'll be confusing if you get to that state by
pulling in to those branches and then find your tree refuses to work.
On the other hand, as Ian points out, APIs based on file ids can't
work across a composite tree containing duplicate ids.  So it's a
tough tradeoff.

Ian> Prefect is the enemy of good in many cases like this. If we're
digging a hole, let's understand why.

The thing I'm worried about here is not so much that we'll be chasing
a perfect solution, but that it will stop moving forward or we will
have irreconcilable differences between developers or that the review
process will be discouraging, which is basically where nested trees
seemed to get stuck previously.  You could debate whether this is a
special case of the former or not, but I think it needs a different
solution: getting agreement or mediation or arbitration on the
approach that people can live with, rather than discussing cutting
features.

In other words we should optimise for doing the least work to get this
to a good state for release, rather than for landing something similar
to what's currently on the table.  You'd think the second implies the
first, but if there is big disagreement it's not.

Is the overall work in a public branch somewhere we could see the
whole thing, rather than just the individual patches?  I don't see one
in <https://code.edge.launchpad.net/bzr>

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