nested trees design-approach : composite trees vs iter_changes

[Martin Pool]

2009/5/8 Andrew Cowie <andrew at operationaldynamics.com>:
> On Wed, 2009-05-06 at 20:40 +1000, Robert Collins wrote:
>> [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].
>
> That's interesting.
>
> So, right now the Linux distro in question maintains its entire tree in
> a single CVS repository, all 13927 packages. I have been looking forward
> to being able to manage this with Bazaar. Right now you've got teams and
> individuals all over the place managing their own trees as "overlays"
> completely separately from the main tree.
>
> Changes, however, are often made to several packages at the same time
> (consider the relations between hal, networkmanager, nm-applet, etc; a
> bug fix in that cluster often involves simultaneous changes or bumps to
> many pieces)
>
> I suppose it would be interesting to have the capability, but
> I'm not sure anyone would need a {sub, netsted, whatever} tree for each
> package, as you suggest.
>
> If they maintained the _sources_ of each package in bzr, and hacked
> their occasional patch or diff there, then certainly, sub whatevers
> would be brilliant. But the Portage tree itself doesn't seem to "need"
> it.

I think it was more of a "here's a not-implausible case for thousands
of nested trees" rather than that Gentoo as it currently exists
specifically wants to do this.

Synchronized changes to multiple packages would probably be better
done if they were all in the one bzr tree.

Alternatively, perhaps people who just want to see one directory would
be happier with a filtered view, as you can do by checking out a
subdirectory in CVS.

-- 
Martin <http://launchpad.net/~mbp/>