scaling of shared storage

[Aaron Bentley]

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

Wouter van Heyst wrote:
> On Mon, Feb 06, 2006 at 09:40:35AM +1100, Robert Collins wrote:
> 
>>One of the things we handwaved in UBZ was the size of the shared
>>inventory store in shared repositories. Even though its quite optimal in
>>an aggregate sense, it will have data from multiple projects commingled.
>>
>>I wonder if rather than a single inventory we had a inventory for each
>>tree root id [yes those things again] this would be more manageable.
>>This implies that the revision would hold the root id itself, so that
>>the inventory would be findable.
> 
> 
> I have the feeling I'm missing some context on tree roto ids. 

Every directory except the tree root has a unique ID.  All tree roots
have the ID "TREE_ROOT".  That means that the roots cannot be
distinguished, and there are contexts in which we wish to.

> Iirc
> tailor generates file-ids on every tailorization, which makes merging
> between two otherwise the same bzr branches made with tailor harder.

Tailor isn't designed to produce the same output every time.
baz-import, for example, is designed to produce the same output every time.

We should support merging between two otherwise-same branches, but we
don't yet.

> Would tree root ids have a similar impact? 

I don't think they would change the issue much.  It's just that there'd
be one more wrong file-id.

> If each 'bzr branch'
> invocation makes a new id it won't, but now I'm again uncertain I
> understand what root ids are supposed to solve.

They are supposed to:
 - make nested by-value trees work better
 - make nested by-reference trees work
 - optimize storage
 - probably other stuff that I'm forgetting

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

iD8DBQFD53MQ0F+nu1YWqI0RAvQyAJwMdNheAIi4q11aUYhskdFOIyzGqwCbBNn1
a2yu2aFRcnmtPuv/wfYMUzg=
=goZ1
-----END PGP SIGNATURE-----