[BUG?] revisiontree's root node has no revision attribute set
aaron.bentley at utoronto.ca
Thu Jul 27 14:57:22 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
John Arbash Meinel wrote:
> What about our idea of splitting up the inventory into a per-directory
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.
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar