syncany-team team mailing list archive

[Fabrice Rossi <Fabrice.Rossi@xxxxxxxxxxx>]

Hi Philipp

Le 12/12/2013 18:15, Philipp Heckel a écrit :
>> http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#crossplatform
>>
> 
> It's good to know how unison does it, but I don't really like the "ask the
> user" concept. I'm more a fan of Dropbox's rename-to-conflict-file
> concept...

I know and I'm sorry to say that I really really dislike it, for
starters because you are only postponing user's intervention without
clearly saying that you need his/her intervention. In fact it's even
worse than that, simply because there is no way to make this renaming nice.

Let's say there are two concurrent modifications to file foo.txt. There
is a common version in the repository. A modifies it and uploads the new
version. Meanwhile B modifies it and tries to upload. This is denied and
B is asked to download the modifications. So far, so good. Now two choices:

1) during the download B's version is moved to foo (conflict).txt, while
A's version replaces B's (current syncany's solution).
2) or the reverse: B's version is left intact, while A is downloaded to
foo (A).txt.

In my opinion, both solutions are completely wrong.

In the first case the user file is modified without his/her consent.
This is against all common sense (starting with the principle of minimal
surprise). In particular Unices do not lock files under editions: let's
say I'm happily editing some files under emacs with unsaved
modifications on foo.txt and bar.txt. I decide to save bar.txt,
triggering the sync up operation. I've to do a down before. If this is
done automatically, bingo, my non saved file foo.txt (which wa modified
on the remote) is silently updated on disk. If this is not done
automatically, I will be notified of the possible conflict (this is
database wide so there might be actually no conflict). I've then to
remember to save everything before manually starting the down and
manually inspecting the possible conflicts. This is insanely complicated
and dangerous.

The second solution is less dangerous but super annoying because it is
unstable: we have foo (A).txt on B which triggers an up, replacing A's
version on the remote with B's. This triggers a down on A with the
apparition on foo (B).txt and again an up, etc.

Notice than both solutions will trigger up operations just after the
down unless conflict files are handled in a specific way.

So, yes, I really really prefer user intervention and something like the
merge conflict lock of git and other version control systems. I also
like a lot the Unison way of synchronizing things it can synchronize and
leaving other files alone until user intervention. Both techniques seem
way less dangerous and way more stable than the dropbox "mess with my
files" technique. For persons like me who want to trust syncany as they
learned to trust git and unison, messing with our files is clearly a
show stopper.

Cheers,

Fabrice