[Sync] Add a new global_id field to sync_pb::TabNavigation

[Sync] Add a new global_id field to sync_pb::TabNavigation

Populate this field from TabNavigation objects (specifically,
the internal value of the timestamp).

BUG=128449
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=161984

[akalin, 2012-10-08 19:29:46]

+zea for sync stuff, +sky for everything else

[sky, 2012-10-08 21:23:30]

LGTM

[Nicolas Zea, 2012-10-08 22:20:55]

https://codereview.chromium.org/11098002/diff/1/sync/protocol/session_specifi...
File sync/protocol/session_specifics.proto (right):

https://codereview.chromium.org/11098002/diff/1/sync/protocol/session_specifi...
sync/protocol/session_specifics.proto:131: optional int64 local_timestamp = 15;
local_timestamp_us?

Also, any reason why we're switching to windows epoch from unix epoch?

[akalin, 2012-10-08 23:26:30]

On Mon, Oct 8, 2012 at 3:20 PM,  <zea@chromium.org> wrote:
>
>
https://codereview.chromium.org/11098002/diff/1/sync/protocol/session_specifi...
> File sync/protocol/session_specifics.proto (right):
>
>
https://codereview.chromium.org/11098002/diff/1/sync/protocol/session_specifi...
> sync/protocol/session_specifics.proto:131: optional int64
> local_timestamp = 15;
> local_timestamp_us?
>
> Also, any reason why we're switching to windows epoch from unix epoch?

I think it's more important to be consistent with the timestamps in
NavigationEntry, esp. since we may use those timestamps as pseudo-IDs.

What do you think?

[akalin, 2012-10-10 00:48:13]

From talking offline, we just need the full-resolution timestamp to globally ID
a navigation.  So instead, I defined a new global_id() field in the protobuf and
populated it from the timestamp.  I think the existing timestamp field suffices
for now (later we'll add a sane timestamp anyway).

PTAL!

[akalin, 2012-10-10 01:49:51]

On 2012/10/10 00:48:13, akalin wrote:
> From talking offline, we just need the full-resolution timestamp to globally
ID
> a navigation.  So instead, I defined a new global_id() field in the protobuf
and
> populated it from the timestamp.  I think the existing timestamp field
suffices
> for now (later we'll add a sane timestamp anyway).
> 
> PTAL!

Per our discussion, I will keep unique_id around and not refresh global_id on
refresh.  Stay tuned.

[akalin, 2012-10-13 01:22:47]

Actually, we should refresh global_id.  But since unique_id is staying around,
that's okay.

[akalin, 2012-10-15 17:09:29]

On 2012/10/13 01:22:47, akalin wrote:
> Actually, we should refresh global_id.  But since unique_id is staying around,
> that's okay.

Nicola, PTAL!

[akalin, 2012-10-15 17:10:17]

On 2012/10/15 17:09:29, akalin wrote:
> On 2012/10/13 01:22:47, akalin wrote:
> > Actually, we should refresh global_id.  But since unique_id is staying
around,
> > that's okay.
> 
> Nicola, PTAL!
+s

[Nicolas Zea, 2012-10-15 19:16:45]

lgtm

[commit-bot: I haz the power, 2012-10-15 19:24:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/akalin@chromium.org/11098002/15001

[commit-bot: I haz the power, 2012-10-15 22:38:09]

Change committed as 161984