commit 964384c88787a12ddd380bbed60a18c1abc6de22
author Dave Borowitz <dborowitz@google.com> Tue May 02 09:30:22 2017 -0400
committer Dave Borowitz <dborowitz@google.com> Thu May 04 09:48:36 2017 -0400
tree f420ed59fdc4555f5af23035bb3439bb1b5e8e55
parent 876c467ec3a7bf9150b3008423a5c903e753a5c7

Properly fuse ref updates into ReceiveCommits's BatchUpdate

Prior to this change, ReceiveCommits collected its own list of
ReciveCommands for inserting and replacing patch sets, and executed them
prior to ever creating a BatchUpdate. This means that when fusing all
ref updates in a BatchUpdate into a single BatchRefUpdate, we still
don't get atomicity between the code and NoteDb refs. This was a major
oversight when writing the FusedNoteDbBatchUpdate implementation.

This behavior in ReceiveCommits was a relic of the pre-BatchUpdate
implementation. It was also more or less unavoidable when using an
earlier incarnation of BatchUpdate, since there were some ref updates
(pushing directly to refs) that weren't associated with a single Change,
so we couldn't pick a Change.Id. Fortunately, we now have RepoOnlyOps.
This is a perfect fit for the problem here: we can produce a 1-to-1
mapping between these extra ref updates and RepoOnlyOps.

It turns out a good chunk of complexity in ReceiveCommits came from
analyzing the patch set creation ref updates to see which ones succeeded
before moving on to the BatchUpdate phase. Now, we can just throw all
the ops into the BatchUpdate, and it will take care of only proceeding
to updateRepo if the ref updates all succeeded. This also subsumes the
corner case of pushing directly to refs/changes/N, which previously we
had to run in a separate update.

We still have separate BatchUpdates for %submit and for pushing to
auto-close changes. But we've eliminated a lot of corner cases.

Change-Id: I50d46e8fe7bf5c02cf5093ee2b93a4607c8316fa