commit/commit-builder/inventory serialisation api friction

[Robert Collins]

We currently pack and unpack and iterate the tree inventory several
times during commit:

in commit.py we iter_entries, giving in-order traversal
that goes entry by entry to the commit builder
which then does a iter_entries again to serialise the inventory
finally/also we read the entire just created inventory  to generate the
cached tree post commit.

I'm wondering about the sanity of streamlining this some more:
commit.py does iter_entries
commit builder outputs to its file object the line for that entry in the
inventory immediately
commit builder returns the right data to update the cached tree in the
dirstate, or none for no-change-vs-left-most-parent
deletes are noted post-iteration to the dirstate for both the working
tree and the basis tree


This might save a reasonably good amount of friction, but it would
couple the iteration order to the inventory serialisation logic, and
maybe thats a nuisance for some inventory types (though those could of
course buffer the entries as needed - 'finish_inventory' would still
exist in the api.

-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/20070914/71ea44b4/attachment.pgp