[RFC] Inventory delta support for CommitBuilder

Aaron Bentley aaron.bentley at utoronto.ca
Mon Aug 27 14:47:38 BST 2007


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

Ian Clatworthy wrote:
> It's the implicit flush() and
> write_inventory() inside apply_inventory_delta that causes the problems
> (performance)...

You should only be calling it once, so how does that cause performance
degradation?

>> Step 2 seems to go against the purpose of dirstate trees, and also seems
>> to go against the idea that inventories will be provided as some kind of
>> delta in packs.
> 
> Did you really mean step 2 here

No, 1.  Sorry.

> Trying to address your bigger picture point about removing inventory
> from APIs as a worthy goal, the new arg (called changes) to
> finish_inventory was taken from the arg to apply_inventory_delta: a list
> of tuples including the new InventoryEntry. It therefore may not be easy
> in the short term to fully hide InventoryEntrys.

We're not trying to hide InventoryEntries, just Tree.inventory.
Tree.inventory necessarily has size-of-tree scaling, so it must die.

> FWIW, there are some UI implementation issues around "pointless commits"
> and verbose reporting that make my think that tracking
> deletions/modifications/additions separately is a good idea.

Separately from each other?  That doesn't make intuitive sense to me,
but you're the coder.

> The new
> Inventory.make_delta_from_edits() method can turn those into the changes
> expected by apply_inventory_delta. I'm mentioning that because that
> tracking of those 3 lists would move into the CommitBuilder if I
> flattened IEs. Not a problem against flattening I hope - just something
> I wanted to mention in case it triggers some further insight you had.

When I came up with the apply_inventory_delta API, it didn't make sense
to me to introduce a flattened format for InventoryEntry.
InventoryEntry has the canonical data, and can be used directly by
WorkingTree.apply_inventory_delta.  Adding another representation for
InventoryEntry seemed like reinventing the wheel.

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

iD8DBQFG0tX50F+nu1YWqI0RAuHkAJ9KuQuU0PZdD87pdXx0T/f1tXgMWgCePlD/
C0sjgcRyZfjIutnwiWO26us=
=aREl
-----END PGP SIGNATURE-----



More information about the bazaar mailing list