nested trees design-approach : composite trees vs iter_changes

Jelmer Vernooij jelmer at
Tue May 5 15:44:50 BST 2009

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.



More information about the bazaar mailing list