[Sync] USS: Ignore encryption changes during conflict resolution 2/2

[Sync] USS: Ignore encryption changes during conflict resolution 2/2

The change plumbs the specifics hash through the worker so it comes back
with the commit response. Originally I intended to pass it through the
commit contribution like the sequence number, but after some thought I
realized that wasn't even necessary for the sequence number so I've
modified the flow to simplify the commit contribution.

BUG=605708
Committed: https://crrev.com/fdd1e5807dd62e08448012773750efe44ecd21bd
Cr-Commit-Position: refs/heads/master@{#391308}

[maxbogue, 2016-04-29 17:19:51]

maxbogue@chromium.org changed reviewers:
+ pavely@chromium.org, skym@chromium.org

[maxbogue, 2016-04-29 17:20:21]

Pavel, Sky, PTAL!

[skym, 2016-04-29 18:43:19]

lgtm

https://codereview.chromium.org/1933803002/diff/60001/sync/engine/worker_enti...
File sync/engine/worker_entity_tracker.h (right):

https://codereview.chromium.org/1933803002/diff/60001/sync/engine/worker_enti...
sync/engine/worker_entity_tracker.h:59: // leveraged to let us fill some
local-only data in on |ack|.
This is phrased like an implementation/definition comment, not a declaration
comment. Why does this data need to be filled?

https://codereview.chromium.org/1933803002/diff/60001/sync/test/engine/mock_m...
File sync/test/engine/mock_model_type_processor.cc (right):

https://codereview.chromium.org/1933803002/diff/60001/sync/test/engine/mock_m...
sync/test/engine/mock_model_type_processor.cc:95:
base::Base64Encode(base::SHA1HashString(specifics.SerializeAsString()),
Is there a reason we Base64 the hash? I realize this is supposed to match the
real proc, but why does the real proc do this?

[pavely, 2016-05-02 19:49:19]

lgtm

[maxbogue, 2016-05-03 17:46:15]

https://codereview.chromium.org/1933803002/diff/60001/sync/engine/worker_enti...
File sync/engine/worker_entity_tracker.h (right):

https://codereview.chromium.org/1933803002/diff/60001/sync/engine/worker_enti...
sync/engine/worker_entity_tracker.h:59: // leveraged to let us fill some
local-only data in on |ack|.
On 2016/04/29 18:43:19, skym wrote:
> This is phrased like an implementation/definition comment, not a declaration
> comment. Why does this data need to be filled?

I moved the bulk of the comment to the implementation.

https://codereview.chromium.org/1933803002/diff/60001/sync/test/engine/mock_m...
File sync/test/engine/mock_model_type_processor.cc (right):

https://codereview.chromium.org/1933803002/diff/60001/sync/test/engine/mock_m...
sync/test/engine/mock_model_type_processor.cc:95:
base::Base64Encode(base::SHA1HashString(specifics.SerializeAsString()),
On 2016/04/29 18:43:19, skym wrote:
> Is there a reason we Base64 the hash? I realize this is supposed to match the
> real proc, but why does the real proc do this?

I'm not sure exactly how SerializeAsString() works, but I imagine it's a lot
easier to deal with strings (for debugging and such) that only have printable
characters instead of just a raw bytestream.

[maxbogue, 2016-05-03 17:46:33]

The CQ bit was checked by maxbogue@chromium.org

[maxbogue, 2016-05-03 17:46:34]

The patchset sent to the CQ was uploaded after l-g-t-m from skym@chromium.org,
pavely@chromium.org
Link to the patchset: https://codereview.chromium.org/1933803002/#ps80001
(title: "Fix comment.")

[commit-bot: I haz the power, 2016-05-03 17:48:05]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1933803002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1933803002/80001

[commit-bot: I haz the power, 2016-05-03 18:41:34]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-05-03 18:43:02]

Description was changed from

==========
[Sync] USS: Ignore encryption changes during conflict resolution 2/2

The change plumbs the specifics hash through the worker so it comes back
with the commit response. Originally I intended to pass it through the
commit contribution like the sequence number, but after some thought I
realized that wasn't even necessary for the sequence number so I've
modified the flow to simplify the commit contribution.

BUG=605708
==========

to

==========
[Sync] USS: Ignore encryption changes during conflict resolution 2/2

The change plumbs the specifics hash through the worker so it comes back
with the commit response. Originally I intended to pass it through the
commit contribution like the sequence number, but after some thought I
realized that wasn't even necessary for the sequence number so I've
modified the flow to simplify the commit contribution.

BUG=605708

Committed: https://crrev.com/fdd1e5807dd62e08448012773750efe44ecd21bd
Cr-Commit-Position: refs/heads/master@{#391308}
==========

[commit-bot: I haz the power, 2016-05-03 18:43:04]

Patchset 5 (id:??) landed as
https://crrev.com/fdd1e5807dd62e08448012773750efe44ecd21bd
Cr-Commit-Position: refs/heads/master@{#391308}