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

--------------
Fei Song
>2015-12-07 11:40 GMT+08:00 Ted Lemon <mellon@fugue.com>:
>
>> Sunday, Dec 6, 2015 10:17 PM Fei Song wrote:
>> > Can we just treat the requests sent by peer B and peer C based on their
>> timestamps (arriving at the server).
>> > If the file must be kept as the same version, different modification
>> reports can be generated independently with FCFS mode.
>> > If this can not be finished automatically, a human intervention will be
>> needed.
>>
>> No, this doesn't work even if you don't care about wiping out changes.
>>  Think about this sequence:
>>
>> 0: File F is at version 0
>> 1: Client A syncs to server
>> 2: Client B syncs to server
>> 3: File f changed on Client A -> Version 0.A
>> 4: File f changed on Client B -> Version 0.B
>> 5: Client B syncs to server, updating file F to version 0.B, modified time
>> = 4
>> 6: Client A syncs to server: what happens?
>>    a: File updated to version 0.A, modified time=3
>>    b: Server overwrites version 0.A with version 0.B, changes in 0.A lost
>>    c: Conflict resolution combines versions 0.A and 0.B, producing version
>> 1, mod time=6
>>
>> I think C is the only right answer.   We want conflict resolution to be
>> automatic whenever possible, but we do want to do conflict resolution, and
>> not just wipe out changes, because those changes may contain real work that
>> the user on client A did.
>>
>Do you mean you want the conflict resolution to be performed every time? If
>so, I think this might be a little bit unnecessary since a version conflict
>is not very frequently happened (especially for some personal users). The
>case you mentioned should definitely be resolved and such offline-to-online
>switch could be treated as concurrent conflict in my view.

For the collaborative working, perhaps we have to do that.

>
>But a more frequent case is that people update their file just to replace
>the previous one, even though there are multiple people working on the same
>file. In this case, replacing file according to modification time seems
>reasonable. So the key point is how to justify which two/more versions
>should trigger the conflict resolution to avoid wiping out real work.

Sure, in un-collaborative case (just for your own file), it's OK.
When multiple people working on the same file (like a source code file), some work should be saved even they are not included in the final version.
This is indeed useful and may contribute as well.

>
>As for the conflict resolution itself, it is very hard to achieve since the
>system needs to handle different types of file. GoogleDocs performs well
>since it only focuses on the documents. But for a storage service, we don't
>know what else types of file will be stored. A popular way I've seen is
>just to keep all the conflicted versions (named by different peers) in the
>storage.

I agree! The target of ISS, I think, should also consider different type of files: documents, video, audio, databases, etc.
How to do the sync among them is very challenging and significant.

>
>>
>>
>> --
>> Sent from Whiteout Mail - https://whiteout.io
>>
>> My PGP key: https://keys.whiteout.io/mellon@fugue.com
>>
>> _______________________________________________
>> Storagesync mailing list
>> Storagesync@ietf.org
>> https://www.ietf.org/mailman/listinfo/storagesync
>>
>>
>