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

[Klaas Freitag <[e-mail]>]

Am 09.12.2015 um 15:35 schrieb Ted Lemon:
> Wednesday, Dec 9, 2015 9:21 AM Jakub Moscicki wrote:
>> Unless you want to dig into the type of the file and explore it’s internal structure to merge, the best you can do is to make sure a version on the server is generated for each conflict file and these may be easily accessible for manual merge by the interested users. For this etags are sufficient. From this point of view there is no difference between conflicts which are generated because two clients update the file at the same time (so conflicting uploads overlapping in time) and a case of offline client which edits locally outdated version (newer version available meanwhile on the server) and consequently uploading it when online again (so conflicting uploads not overlapping in time). In both cases it looks to me good enough if they end up as versions on the server for manual user merge/revert.
> 
> Most files are text files, which are easy to merge, so yes, I do want to be able to dig into the structure of the file.   Even when the file isn't "easy to merge," e.g. a sound file or a drawing, knowing the order of the changes can be very helpful when someone is doing a manual merge.   And you can build merge tools for commonly-merged files; if conflict detection is a feature of the data store, then there's an incentive to build such tools, whereas if everybody is accustomed to dumb data stores that don't provide this feature, there's no point in making merge easy.
Automatically mergeable or not, I don't think resolving conflicts shoudl
be part of the sync protocol. Of course conflicts must be detected and
hooks should exist to plug in code to work with it, but I doubt it
should be part of the sync layer to interpret and resolve them.

And even if there is an automatic resolving of conflicts for some file
types (that is obviously possible if that is wanted from a higher level
point of view) there always remains the possibility of not at all
automatically mergeable conflicts.

I am also not sure about the importance of the sequence of changes, as
there are situations caused for example by offline work, where changes
happen in parallel, these cause a conflict, and it's not really
important which change was before or after. Important is that both
versions can be found again, but not necessarily in timely order.

I do not understand why Kuba said "Etags are sufficient" in this
context, but maybe I lack context because I am late to the party...

regards,

Klaas


> 
> The absence of this feature is a serious problem in my workflows; I don't know if your experience is similar.   I don't really see any point in inventing "yet another" storage sync mechanism that doesn't provide this feature.   E.g., do you really want a calendaring system that automatically re-adds files that have been deleted on one client when a second client connects that hasn't seen the deletion?   An address book that backs out updates?   A mail system that undeletes deleted messages, or deletes messages on the client that were lost on the server due to a crash?
> 
> The use case of a small collection of large files used entirely sequentially is easy to address, but (a) not very interesting and (b) not actually a common use model.   It _seems_ common because we don't provide anything better, and so people make do with it, but it doesn't actually fit with what they are doing.   If it did, we wouldn't see the proliferation of manually-labeled versions of the same file that is so common in such data stores.
> 
> 
> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/[e-mail]
>