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

[Ted Lemon <[e-mail]>]

Monday, Dec 7, 2015 1:45 AM Linhui Sun wrote:
> 2015-12-07 11:40 GMT+08:00 Ted Lemon <[e-mail]>:
>> 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.

It really depends on the use case.

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

This use case is a common use case for folders that are used informally as a way to transfer files between users.   Typically each version of the file actually has some kind of version in the filename -- e.g., "SoW 2015/11/1 10am Ted" and we just expect the users to manage versions.   In this use model, you definitely don't need to do anything fancy.

However, this is a really broken use model, which exists because the tools don't work well enough to do something sensible.   They don't allow you to track versions, they don't allow multiple committers, and they don't have a mechanism for resolving conflicts when two people change the same version of the file and try to upload the change.

> 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 think this is a valid conservative way of approaching the problem.  But what makes sense to me is that the sync service be able to identify conflicts, and that there be a conflict resolution process at a layer above the sync service.   The conflict resolution process could do something trivial like resolving the conflict by making a new file with the same name plus a well-understood notation like "conflict Ted/Sun 15/11/7". 

This would be similar to what people would do if there were no conflict resolution layer.   But if you have a file type for which there is already an automatic conflict resolution process, then the conflict resolution process can just do that resolution.   There's no reason to pick a one-size-fits-all approach to this problem.   What matters is the ability to know that a conflict has occurred based on the versioning information in the metadata.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/[e-mail]