tree 58b66e0ce554dec202f2e10e1e5baed682a30a95
parent b74653274cc5d225152defedff607399a7e6eb50
author Dave Borowitz <dborowitz@google.com> 1428009624 -0700
committer Dave Borowitz <dborowitz@google.com> 1428009624 -0700

MergeOp: Retry when current revision is not found

We were unconditionally setting the change back to NEW if there was
some unknown error attempting to merge a change. Be a little more
precise about what we do with REVISION_GONE. In particular, in a
replicated environment with eventually-consistent semantics (whether
master-slave or multi-master), a revision might be missing due to
replication lag, which might eventually correct itself. So, we
shouldn't reset the change to NEW in this case, allowing the submit
queue to eventually pick it up once replication settles out.

We can also make the message a little nicer. Like other merge failure
messages, this one is repeated only occasionally if it is a duplicate.
This does mean that if the failure is not due to replication lag but
something else (the kind of thing this code was originally worrying
about, e.g. the ref got manually deleted), we might continue retrying
indefinitely. This is not so bad; there are already plenty of cases
where we do that, and that's why we implemented the message
deduplication in the first place.

Change-Id: I2f8d2ab1bc3938dbc0573dc5a319f03bb546b5f1