commit-performance and iter_changes
robertc at robertcollins.net
Mon Nov 10 08:18:25 GMT 2008
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.
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081110/c58fae5e/attachment.pgp
More information about the bazaar