On 8/7/13 6:13 PM, Chris Karlof wrote: > In general, queue sync as described doesn't maintain much history for > merging.
Yeah, I think there's a spectrum in which the more history we retain, the better job of merging we can do. But I'm not convinced it's worth storing a whole lot. We have to be able to handle the no-shared-history initial merge anyways, so if things get too far out-of-sync, we can always fall back on that. Having the server do collection-wide compare-and-swap gives us a linear central history. Putting integer labels on this history (and assuming the server never rolls back) lets clients tell when they can fast-forward and when they need to rebase, but doesn't let them re-create the common ancestor (unless they remember it themselves, with a shadow copy or reverse-deltas or something). If the server rolls back and then doesn't move forward past the client's revision number, we can detect it, but if the server moves past that point, we couldn't tell that we've lost a change. That's probably enough. The next steps up the spectrum would be: * Label history with integer+nonce. That marginally improves server rollback detection (if client_rev_number == server_rev_number, but the nonces don't match: rollback). * Add a parent-revision field to each change. That adds a tiny bit more rollback detection. * Retain N previous changes: more rollback detection, enable clients to (sometimes) fetch the common ancestor, and rebase one-change-at-a-time instead of trying the whole delta. * Retain all previous changes (full Git model). Enables perfect rollback detection, always finding the common ancestor (if there is one). But right now, I'm thinking that the cheapest/good-enough-est answer is to go with integer revision IDs, some kind of manual server-side rollback announcement (if we lose a datacenter and must recover from backups, we set a flag on each account that says "hey clients, do a full re-sync"), and if the client falls too far behind, we resync. cheers, -Brian _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
