commit-performance and iter_changes

[Robert Collins]

So, we've wanted to use iter_changes for commit for some time, but its
been tricky, because we calculate merge info on merge commits and that
requires doing more processing of the entire tree.

I think that a moderate shift in interface to be even more delta
orientated in CommitBuilder will allow us to do this sensibly...

I see it working something like this:

 - tree to commit builder interface is a delta - iter_changes basically
 - on merge commits the commit builder is responsible for comparing the
   merged-in-tree with the basis to determine what nodes need
   last-changed fields updated
 - in xml repositories we can generate a delta (basis, each parent) to
   get a set of possibly different entries that we need to consider
 - in split-inventories we can parallel-diff all the inventories at once
   to achieve the same; 

We can likely also optimise by looking for V shape differences only
during this phase.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081110/c58fae5e/attachment.pgp