scaling of shared storage

[Aaron Bentley]

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

Jan Hudec wrote:
>>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.
> 
> 
> The question is whether /that/ actually helps anything. 

I think that it would help on a project with tens of thousands of
revisions.  You'd split at annotations, of course.

> That is how much
> it helps after knits are in. On the other hand splitting inventory
> per-directory certainly does help anything (most projects contain
> directories they touch rarely) 

So what about the projects that don't contain directories they touch
rarely?  Depending on user behaviour to ensure good scaling seems
dubious to me.

> and it would make branching a subtree
> some bits simpler. Which I think would be an important feature - you may
> often realize you want to split out some part as library only after a
> while when it grows to substantial size.

You'll have to clarify how that would make it simpler.

>>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)
> 
> 
> Maybe not even that. When you add a file, all it's parent directories
> need to get added automatically -- which includes root. revert -r 0
> deletes the root... you get a new project when you add it again, but
> I think that's OK -- while the operation is legal, it's hardly sensible.

I don't believe it is possible or desirable to delete the CWD.

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

iD8DBQFD53XE0F+nu1YWqI0RAqXaAJ9houYd0XJf/Qc/+kCy+SYEjvrz4gCdHxex
UU7pjAj3dUfXZsLm1BY7oLo=
=BGIW
-----END PGP SIGNATURE-----