[RFC] Removing the inventory concept from Bazaar.

Aaron Bentley aaron.bentley at utoronto.ca
Tue May 8 16:12:13 BST 2007


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

Daniel Silverstone wrote:
> On Tue, 2007-05-08 at 09:22 -0400, Aaron Bentley wrote:
>> Inspired by Robert's post, I started thinking about improving our
>> scaling in large trees.  I decided to take the extreme approach of
>> removing inventories as a concept, to see what broke.
>>
>> It seems to work, so I've started a draft spec here:
>> http://bazaar-vcs.org/DraftSpecs/NoInventory
> 
> Your third assumption is that you can add a noop record to every
> unaffected knit index on commit

Yes, but I had hoped that the constant factors would be small enough
that we could get away with it.

The motivation for no-op commits is so that we can look up the content
of a file-id for a given revision efficiently.  Currently, this
operation is done using the inventory, so it scales O(n).

Robert and I have been exploring some alternative approaches to looking
up content efficiently.  He proposed maintaining a file-id ->
revision-id file.  I think maybe we can leverage the revision history to
find the latest version of a file.

> Won't this mean that commit time will be proportional to size of tree
> not number of modifications?

Yes, but I can imagine a very, very small constant factor, because we'd
only be adding a knit index entry.

> Also, won't this mean that a push will always have to update every knit
> index? Seriously increasing the potential number of round trips?

That is more worrying.

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

iD8DBQFGQJNN0F+nu1YWqI0RApbZAJ9WigFNwCUFzYtZLF06XngLwA+62gCeMSdC
h5kOtPgefE3tfFkSQNXKUsw=
=kOOk
-----END PGP SIGNATURE-----



More information about the bazaar mailing list