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

[Linhui Sun <[e-mail]>]

2015-12-08 1:57 GMT+08:00 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.
>
Yes, and this use case should be considered.

>
> > 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.
>
That's better. It seems that a separate layer for conflict resolution is
well accepted. But for etag and versioning metadata, which to employ still
needs to be discussed. Any comments for that?

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