commit/commit-builder/inventory serialisation api friction

[Ian Clatworthy]

Robert Collins wrote:

> commit builder returns the right data to update the cached tree in the
> dirstate, or none for no-change-vs-left-most-parent

This bit is good.

> deletes are noted post-iteration to the dirstate for both the working
> tree and the basis tree

This bit is good.

> 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.

I don't think CommitBuilder should dictate to callers the order in which
things must be passed. It's perfectly fine for it to be fastest in a
given order but it needs to be robust enough to support an alternative
one. In practice, that probably translates to:

1. record_entry_contents can buffer serialised entries
2. finish_inventory should sort just to be sure.

As you might recall, I was proposing in an earlier patch that
finish_inventory took an inventory delta. I still suspect that will give
us the most flexibility longer term.

Ian C.