Some thoughts about splitting the inventory according to subdirectories

[Aaron Bentley]

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

Matthieu Moy wrote:
| It has been mentionned here that bzr might move to an inventory format
| using one file per directory.
|
| The obvious benefit is to avoid having to parse the complete inventory
| file when working on subdirectories.

I think, in general, that only operations which do not write to the
inventory can do this.  Any operation that writes to the inventory must
ensure that the inventory contains no inconsistencies.

So operations like revert, which uses the inventory to look up the
file-id, to compare it to previous versions, might benefit.

| make sure other people have realized it too): if each parent inventory
| points to its subdirectory inventories with a checksum (or if you have
| somewhere a meta-inventory pointing to all inventory files), then it
| becomes possible to compare two inventories in O(number of files in
| modified directories) instead of O(total number of files).

I think it's an error to rely on the user to subdivide files in such a
way that we perform efficiently.  I believe a better way to achieve this
kind of performance improvement would be to use arbitrary trees, perhaps
based on the full file path.  I believe solutions based on this approach
have O(log(n)) scaling, regardless of the directory structure of the
project.

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

iD8DBQFEAgNB0F+nu1YWqI0RArzpAJ9KWOxM2vC66sH/0sOr9aZrypdUrgCfa8H+
zetI/NwLSWGEURhLC7bUgrU=
=Yw7W
-----END PGP SIGNATURE-----