Migrate startup URLs pref.

chrome/browser/prefs/pref_model_associator.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CHROME_BROWSER_PREFS_PREF_MODEL_ASSOCIATOR_H_
 #define CHROME_BROWSER_PREFS_PREF_MODEL_ASSOCIATOR_H_
 
 #include <map>
 #include <set>
 #include <string>
@@ skipping 93 matching lines @@
   void AddSyncedPrefObserver(const std::string& name,
                              SyncedPrefObserver* observer);
 
   // Removes a SyncedPrefObserver from a pref's list of observers.
   void RemoveSyncedPrefObserver(const std::string& name,
                                 SyncedPrefObserver* observer);
 
  protected:
   friend class ProfileSyncServicePreferenceTest;
 
-  typedef std::map<std::string, syncer::SyncData> SyncDataMap;
+  typedef std::vector<std::pair<std::string, syncer::SyncData> >

[Nicolas Zea, 2013/10/10 17:44:14]

why switch to a vector? I think a map is still correct.

Consider, for example, the case where you have both a synced version of the new
preference and one of the old preference, and they don't match with the local
version of the new preference.

As you're iterating, you'll encounter the synced version of one with value A,
merge it with the local version with value L, and wind up with AL as the new
synced value you need to push back to the old pref. You'll then continue, see
the second synced pref with value B, merge it with the local value AL, and wind
up with ABL, which is _now_ the value you should be syncing back to _both.

I think it would make more sense to use a map, so that the second time you
generate the value, you'll overwrite the first value (although in practice
passing two changes to the same value is the same as just passing the second
change).

[robertshield, 2013/10/10 20:06:21]

Ok, I hadn't understood that MergeDataAndStartSyncing could iterate over the
same preference name multiple times. I've switched it back to a map.

[Nicolas Zea, 2013/10/10 20:35:09]

Well, it's not that MergeDataAndStartSyncing will iterate over a preference
multiple times (the SyncDataList has only one of each synced preference), it's
that we may wind up with multiple writes to the same migrated preference.

[robertshield, 2013/10/11 18:29:31]

Done.

+      SyncDataPrefList;
 
   // Create an association for a given preference. If |sync_pref| is valid,
   // signifying that sync has data for this preference, we reconcile their data
   // with ours and append a new UPDATE SyncChange to |sync_changes|. If
   // sync_pref is not set, we append an ADD SyncChange to |sync_changes| with
   // the current preference data.
+  // |migrated_preference_list| points to a vector that may be updated with a
+  // string containing the old name of the preference described by |pref_name|.
   // Note: We do not modify the sync data for preferences that are either
   // controlled by policy (are not user modifiable) or have their default value
   // (are not user controlled).
   void InitPrefAndAssociate(const syncer::SyncData& sync_pref,
                             const std::string& pref_name,
-                            syncer::SyncChangeList* sync_changes);
+                            syncer::SyncChangeList* sync_changes,
+                            SyncDataPrefList* migrated_preference_list);
 
   static base::Value* MergeListValues(
       const base::Value& from_value, const base::Value& to_value);
   static base::Value* MergeDictionaryValues(const base::Value& from_value,
                                             const base::Value& to_value);
 
   // Do we have an active association between the preferences and sync models?
   // Set when start syncing, reset in StopSyncing. While this is not set, we
   // ignore any local preference changes (when we start syncing we will look
   // up the most recent values anyways).
@@ skipping 40 matching lines @@
       SyncedPrefObserverMap;
 
   void NotifySyncedPrefObservers(const std::string& path, bool from_sync) const;
 
   SyncedPrefObserverMap synced_pref_observers_;
 
   DISALLOW_COPY_AND_ASSIGN(PrefModelAssociator);
 };
 
 #endif  // CHROME_BROWSER_PREFS_PREF_MODEL_ASSOCIATOR_H_