One very useful concept that ought to be tossed-in to the design of such a system is that of generations.   Each time a change to a record is accepted, a new “generation” of that record is created, and if you ask for “the record” you are given the latest generation of it, but all of the generations are kept.

You also aggressively use the notion of “unique identifiers,” or as I like to call them, monikers.   Monikers are associated with the identity of the base-document, and other monikers are also associated with every generation.   So, when a particular user wants to synchronize, there is never any ambiguity to figure-out.   The client software can hand you an unambiguous list of exactly what he’s holding, and can likewise refer unambiguously both to “the thing being updated” and to “the update itself.”   (If you use a well-known algorithm such as UUID, notice that clients can generate monikers too, and those monikers will never “crash” against anybody else’s.   A provably-strong message digest algorithm, such as SHA1, provides a useful field-value that can be used to detect differences between the various stored items.)

I believe that these are two most-important elements of any data synchronization design:   retaining all copies of the information, and removing all sources of ambiguity.   Message-digests and UUID-based monikers are completely unambiguous, and they’re short-n-sweet.