nested trees design-approach : composite trees vs iter_changes

[Robert Collins]

On Wed, 2009-05-06 at 18:48 +1000, Ian Clatworthy wrote:
> Robert Collins wrote:
> > On Tue, 2009-05-05 at 10:19 -0400, Aaron Bentley wrote:
> 
> >> Instead, you have been undermining me.  I don't like being vetoed, but
> >> it is better than being undermined.  It is at least direct.  It
> >> demonstrates that your objections are strong enough that you're willing
> >> to derail the current development over them, and that's important data.
> > 
> > Concerns that aren't addressed rarely just go away; trying to get it
> > discussed wasn't intended to be undermining, but an attempt to get it
> > discussed!
> 
> And I certainly took your email in that light. From my perspective, the
> primary issue was the relatively late veto/articulation of your
> concerns. It's *extremely* frustrating to do a pile of work, go through
> multiple reviews and then have something vetoed a month or two afterwards.

Indeed; and as I've said I really didn't want to veto here; its way too
heavy a hammer.

I don't have a particular attachment to any particular design here
either: if a majority of core are happy with the design as it stands,
after this thread - thats fine with me. My concerns are driven solely
based on what we've learnt about users and scalability. [For instance,
consider a portage/ports tree in bzr - users do this today, and a not
unreasonable use case is for each package to be a nested tree. In that
case a index of nested trees will be about the same size as the main
inventory, and contain no new information].

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090506/76240ff7/attachment.pgp