sync: Remove the remaining conflict sets code

chrome/browser/sync/engine/syncer_types.h

Index: chrome/browser/sync/engine/syncer_types.h
diff --git a/chrome/browser/sync/engine/syncer_types.h b/chrome/browser/sync/engine/syncer_types.h
index e4fde71467aee67f013160080d09c025aa73b295..c9bfc83b77fa5abb5b901267069058523648d950 100644
--- a/chrome/browser/sync/engine/syncer_types.h
+++ b/chrome/browser/sync/engine/syncer_types.h
@@ -30,15 +30,29 @@ enum UpdateAttemptResponse {
   // Update was applied or safely ignored.
   SUCCESS,
 
-  // Conflicts with the local data representation. This can also mean that the
-  // entry doesn't currently make sense if we applied it.
-  CONFLICT,
+  // The conditions described by the following enum values are not mutually
+  // exclusive.  There can exist updates to unsynced items that would cause
+  // hierarchy conflicts and also can not be dectrypted right now.  The list has

[Nicolas Zea, 2012/02/01 19:16:19]

detcrypted

[rlarocque, 2012/02/02 00:32:56]

Done.

+  // been ordered according to priority in the case of overlap, with highest
+  // priority first.  The example given above would be treated as

[Nicolas Zea, 2012/02/01 19:16:19]

Example given above?

[rlarocque, 2012/02/02 00:32:56]

I was trying to refer to the example two sentences ago, but I think I've
refactored the wording to the point that that's no longer clear.  Will fix.

+  // CONFLICT_ENCRYPTION, even though it would be not incorrect to describe it
+  // as a CONFLICT or HIERARCHY_CONFLICT.

[Nicolas Zea, 2012/02/01 19:16:19]

Mention that CONFLICT_ENCRYPTION and CONFLICT_HIERARCHY are nonblocking
conflicts, in that we do not attempt to resolve them or have logic based on
their existence, and rely on a later update allowing us to apply them
successfully.

[rlarocque, 2012/02/02 00:32:56]

Done.

 
   // We were unable to decrypt/encrypt this server data. As such, we can't make
   // forward progress on this node, but because the passphrase may not arrive
   // until later we don't want to get the syncer stuck. See UpdateApplicator
   // for how this is handled.
-  CONFLICT_ENCRYPTION
+  CONFLICT_ENCRYPTION,
+
+  // These are some updates that, if applied, would violate the tree's
+  // invariants.  Examples of this include the server adding children to locally
+  // deleted directories and directory moves that would create loops.
+  HIERARCHY_CONFLICT,

[Nicolas Zea, 2012/02/01 19:16:19]

Prefer CONFLICT_HEIRARCHY

[rlarocque, 2012/02/02 00:32:56]

Done.  I assume you meant CONFLICT_HIERARCHY.

+
+  // This indicates that item contains both an unapplied update and an unsynced

[Nicolas Zea, 2012/02/01 19:16:19]

This indicates that the item was modified both remotely (is_unapplied_update)
and locally (is_unsynced). We use the ConflictResolver to decide which of the
changes should take priority or if we can possibly merge the data.

+  // change.  The ConflictResolver should be used to decide which of the changes
+  // will take priority.
+  CONFLICT

[rlarocque, 2012/02/02 00:32:56]

I renamed this to CONFLICT_SIMPLE, just to be consistent.  I also renamed a
bunch of related methods, too.

 };
 
 enum ServerUpdateProcessingResult {
@@ -132,14 +146,6 @@ class SyncEngineEventListener {
   virtual ~SyncEngineEventListener() {}
 };
 
-// This struct is passed between parts of the syncer during the processing of
-// one sync loop. It lives on the stack. We don't expose the number of
-// conflicts during SyncShare as the conflicts may be solved automatically
-// by the conflict resolver.
-typedef std::vector<syncable::Id> ConflictSet;
-
-typedef std::map<syncable::Id, ConflictSet*> IdToConflictSetMap;
-
 }  // namespace browser_sync
 
 #endif  // CHROME_BROWSER_SYNC_ENGINE_SYNCER_TYPES_H_