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

[Linhui Sun <[e-mail]>]

2015-12-07 11:40 GMT+08:00 Ted Lemon <[e-mail]>:

> 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.

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.

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.

>
>
> --
> 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
>
>