[BUG?] revisiontree's root node has no revision attribute set

Aaron Bentley aaron.bentley at utoronto.ca
Thu Jul 27 14:57:22 BST 2006

Hash: SHA1

John Arbash Meinel wrote:
> What about our idea of splitting up the inventory into a per-directory
> entry.

I'm not generally keen on that idea.  I don't want to rely on the users
having sane directory structure in order to get good performance.

And I think it may well be a performance loss, because now we're having
to retrieve many directory objects to build a real Inventory.

> And then the root node has a place to go. 

Don't follow.

> Directories would be
> updated every time there was a content change (so they get the
> revision_id of the last change to anything beneath them).

I'm not sure whether this is a win.  That's a lot of thrashing for the
upper-level directories.  It also means changing object behaviour, and
presumably rewriting history.

> I worry a little bit about performance.
> We trade off having a single huge inventory.knit in exchange for having
> to read several inventories to do a pull.

Several inventories, each in a different knit?

> *However* we gain back the ability to not download all of those files,
> because we can tell what directories have changed.

But any change in a subdirectory is going to require us to retrieve
multiple InventoryDirectories, which may well be a loss over retrieving
a single Inventory.

> If we have to change the inventory format which means we have to change
> the Repository format (so old client know they can't use it), it might
> be worthwhile to investigate the benefits/weaknesses of splitting up
> into per-directory inventories.

I'd like to avoid intermixing the critical paths.  So I'd like to update
Inventory and Repository for nested-trees separately from this work.

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


More information about the bazaar mailing list