nested trees design-approach : composite trees vs iter_changes

[Ian Clatworthy]

Vincent Ladeuil wrote:
>     robert>  * The CT design enforces 'file ids are unique' across all the nested 
>     robert>    trees; this perhaps not meant to be a long term constraint, but it 
>     robert>    is one that we can't enforce - unlike our normal behaviour users
>     robert>    will be able to make bzr break, and it won't be clear why, or how
>     robert>    they should fix it (and arguably they won't have done anything
>     robert>    wrong that would need fixing).
>
> It also forbids using two (or more) different revisions of the
> "same" nested tree. Imagine that you want to use the nested trees
> for backward compatibility handling for example, by using a
> nested tree for each released version of a particular
> library. I'm sure other use cases exist.
>   

Huh? I don't understand your Use Case at all. If you want different
revisions, what's wrong with different branches?

Right now, we have a heap of APIs that take file-ids as unique IDs into
a tree. We *actively* encourage that instead of using pathnames! If
we're dropping file-ID as being unique across a 'tree', do those APIs
need to take a tree-id,file-id tuple in order to uniquely reference the
item? That sounds like a very disruptive change. I personally don't
think insisting on unique IDs across trees *to start with* is
unreasonable, though we ought to check that constraint is met when a
nested tree is added.

Let's focus on the end user and recognise that *a* solution soon is
better than a perfect solution at some unknown time in the future. Let's
also recognise that this is a complex feature and that it's unlikely any
of the designs will be optimal until we've had at least 6-12 months of
usage to uncover issues we're yet to imagine. If there are user problems
with Aaron's approach, let's hear them and discuss solutions. If there
are implementation issues, let's keep the public API changes to an
absolute minimum so we have flexibility in addressing them going
forward. I don't think dropping Aaron's existing work and changing the
design - swapping one set of issues for another set - is the best way to
proceed, but I'm interested in hearing why people think otherwise. It
may be possible to tweak Aaron's approach to address the concerns.

To summarise, I think everyone needs to be extremely careful about what
they wish for w.r.t. nested trees or it will be another 2 years until we
deliver this feature. Prefect is the enemy of good in many cases like
this. If we're digging a hole, let's understand why. But let's not
forget that we're the only major tool without this feature and no
solution at all is a pretty damn big hole already.

Ian C.