Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1

[Jakub Moscicki <[e-mail]>]

Unless you want to dig into the type of the file and explore it’s internal structure to merge, the best you can do is to make sure a version on the server is generated for each conflict file and these may be easily accessible for manual merge by the interested users. For this etags are sufficient. From this point of view there is no difference between conflicts which are generated because two clients update the file at the same time (so conflicting uploads overlapping in time) and a case of offline client which edits locally outdated version (newer version available meanwhile on the server) and consequently uploading it when online again (so conflicting uploads not overlapping in time). In both cases it looks to me good enough if they end up as versions on the server for manual user merge/revert.

kuba

--

> On 09 Dec 2015, at 15:11, Ted Lemon <[e-mail]> wrote:
> 
> Wednesday, Dec 9, 2015 7:22 AM Markus Unterwaditzer wrote:
>> By file-conflict I mean just the condition that both remote (the server) and local (the sync client) have changed since the last sync, and it is therefore undecidable which version of the file to use.
> 
> Sure.   This takes care of the most trivial case of a conflict, but does not retain enough information to detect interleaved conflicts, where for example one client makes a change based on version X of the file, a second makes a change based on version X+1, the second one commits, and then the first one commits.   In your case, automatic conflict detection would undo changes in the file that had been made between versions X and X+1, because neither the client nor the server has any record of what the sequence of changes was.
> 
> 
> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/[e-mail]_______________________________________________
> Storagesync mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storagesync