nested trees design-approach : composite trees vs iter_changes

[Jelmer Vernooij]

Robert Collins wrote:
>  * Because trees won't be responsible for their own nested items, it 
>    may/will be very tricky for bzr-svn to do the right thing with
>    externals [it may need to represent them as something different
>    again, though I'm not 100% sure about that].
>   
FWIW, This is not an issue for foreign branches, at least not for
bzr-svn (svn:externals) or bzr-git (submodules); I'm not sure about
bzr-hg (not familiar with how externals work there). I've started
working on svn:externals (lp:~jelmer/bzr-svn/nestedtrees2) using the
currently proposed APIs (mainly to see if I had to give feedback to
Aaron) and have got basic support for externals going. The main thing
that's missing as far as I can tell is support for nested trees with
revision "current:" rather than an explicit revision, but that seems
unrelated to your concerns.

I like how the UI and file formats for nested trees are shaping up,
they're nice and clean. I agree that requiring special handling of
nested trees for API users is a pity, but I think it's a reasonable
tradeoff for now.

Cheers,

Jelmer