tree f8f501180790684f759a5a6a043f4cfc5c3ca0f2
parent b6d60b137831e0e07ff108810c026dbfb9bf3160
author Dave Borowitz <dborowitz@google.com> 1452635083 -0500
committer Dave Borowitz <dborowitz@google.com> 1455635268 +0000

Don't aggressively flush objects when merging

This is a long story. We originally tried this about a year ago with
Ia85c5114, but that was doomed (reverted in Id691318a) as we couldn't
guarantee PatchSet objects wouldn't be written before the inserter was
flushed. That experience directly led to the introduction of
BatchUpdate in I0771f5e8, which finally culminated in converting
MergeOp to BatchUpdate in I1d9883a5[1].

Now, we can close the door on this chapter and finally avoid flushing
each new commit as soon as it's created. It is now easy to prove that
no PatchSets are written pointing to new SHA-1s before they are
flushed, since commits are created in updateRepo and patch sets are
updated in updateChange.

The lone exception is in CherryPickChange, where the BatchUpdate
creation can't easily be hoisted higher, because we have to parse
objects from the repo in order to determine which Change.Id the
operation applies to. But here we can ensure flushing happens by
passing the same ObjectInserter to any BatchUpdates.

This should substantially improve performance of all merge strategies
that create one commit per submitted change (MergeAlways, CherryPick,
RebaseIfNecessary), particularly on slow backends.

[1] The astute reader will notice I have also justified the existence
    of BatchUpdate as making the notedb transition easier by being one
    place to create ChangeUpdates, enforce ordering, eventually have
    retry logic, etc. That is all true, but it turns out it's not the
    original motivation.

Change-Id: Icba6262383088fe24b81ec7159511d80ae31724e