nested trees design-approach : composite trees vs iter_changes

[Andrew Cowie]

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.

Maybe I'm missing something.

AfC
Sydney
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090508/a6086aa0/attachment-0001.pgp