nested trees design-approach : composite trees vs iter_changes

[Vincent Ladeuil]

>>>>> "Ian" == Ian Clatworthy <ian.clatworthy at canonical.com> writes:

    Ian> 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.
    >> 

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

The use case is about using one subtree at two different
revisions inside the *same* branch.

Say you want to test the smart server at revision
lp:~/bzr/bzr/current and lp:~bzr/bzr/bzr.dev for example and you
embed directories containing bzr at these two revisions.

      Vincent