[bsaul]

Seems to me like the merge part of the algorithm is a bit overkill :

Generate a uuid for each item on your list upon creation ( on the client side), then sync the actions on the item ( create, update, delete). There's never the need to "merge" on the server. All you need is to create a serial "history" of all the actions on the server side, and replay them in that order on clients. You do that by locking on the DB when a client wants to send new actions.

PS : i'm currently coding exactly that. So it's more a way for me to share my ideas rather than criticize.

[mphillips]

I'd be really interested to hear more about your approach. Maybe you’d write it up?

I did consider simply storing and replaying actions, but realised I'd still want a way to merge them: consider a series of actions like: "add item", "update item", "add item", ...<lots more changes>..., "delete items 1 through 20". If there’s no merge, a lot of redundant actions will end up building up in the offline case.

There are a lot of ways to approach this (I’m reading Brent Simmon’s adventures (http://inessential.com/2014/05/24/vesper_sync_diary_follow-u...) with interest at the moment).

[bsaul]

Yes i realized that it may be a bit long if one needs to sync everything from the start. You may have to build a "compacted" history where all the items that will later be removed are excluded. The thing is it's more of a compression of serial actions than a merge between forked branches ( which makes things easier).