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 -- Mailing list: https://launchpad.net/~syncany-team Post to : [email protected] Unsubscribe : https://launchpad.net/~syncany-team More help : https://help.launchpad.net/ListHelp
