scaling of shared storage

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> I think the best mention was to split up the inventory so that you had
> each directory having just its inventory, and then the base inventory
> becomes the tree root id.

I'm not sure about this; it seems like a half-measure.  There's nothing
preventing bad scaling behaviour *within a project* this way.  So I
think we may want to split inventories further, perhaps every 100
revisions, or every x bytes, or something.

> We need tree root ids to properly support nested branches anyway (both
> by-value and by-reference work better with a root id).
> 
> Right now, you could find it because you have other meta-information
> (you have the working inventory). But you are completely correct. Each
> revision would need to add a 'tree-root-id' parameter, so that we can
> look up in remote.

I think in previous emails, we got as far as the idea of calling the
tree-root-id the 'project-id', and using it for other things.  It might
be useful to the launchpad folks, for example.  Anyhow, I'm pro ids for
tree roots.

But last time, we were setting a tree-root-id for the NULL revision, and
I think that was wrong, because the NULL revision should be the same, no
matter what project you're talking about.

This implies that the tree root is added in the first revision, and that
is okay with me.  I will happily make whatever changes are needed to
avoid actually creating / deleting the root directory.  (Though the way
branch creation works, I don't think we need to do that.  Probably we
just need to make it illegal to revert to -r 0)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD52lo0F+nu1YWqI0RAgg5AJ9QIspgu9oDG1kfdugQMsefh5U5vwCdELQe
C36DMukJYh+fWY+D+cD30aw=
=MayI
-----END PGP SIGNATURE-----