[RFC] Removing the inventory concept from Bazaar.
aaron.bentley at utoronto.ca
Tue May 8 16:12:13 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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:
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar