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

["Fei Song" <[e-mail]>]

--------------
Fei Song
>Sunday, Dec 6, 2015 9:16 PM Linhui Sun wrote:
>> Right. Conflict resolution is a layer above syncing. Could be automatic, could
>> require human intervention (although that's best avoided if possible). Concurrent conflict (e.g. Real-time edit) might/should require human
>> intervention. But the non-concurrent conflict (e.g. modification caused by
>> different peers but not at the same time) should be automatically resolved by
>> the system. Ideally you have a way to go back and undo a change if something important was
>> lost or overwritten. This is another reason why keeping a versioned metadata
>> store is good.
>
>Nope, this doesn't always work.   E.g., peer A is acting as the central server, and peers B and C are disconnected, and while disconnected, both modify file F.   When they reconnect, it's not the case that the later modification to file F can be considered to supersede the earlier modification.   Because both clients modified the same version of the file, what you probably want is for the changes that B made and the changes that C made to be merged.   Often this can be done automatically, but not if both changes are to the same part of the file, and are not the same change.

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.

>
>Merges can also be a problem if there are cross-file dependencies.

indeed.

>
>So the bottom line is that you do need to be able to run a conflict resolution process after an update.  But it's not part of the update--it's a separate step, which may result in _another_ update once it's completed.
>
>
>--
>Sent from Whiteout Mail - https://whiteout.io
>
>My PGP key: https://keys.whiteout.io/[e-mail]