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

"Fei Song" <fsong@bjtu.edu.cn> Sat, 12 December 2015 13:48 UTC

Return-Path: <fsong@bjtu.edu.cn>
X-Original-To: storagesync@ietfa.amsl.com
Delivered-To: storagesync@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4E01A8789 for <storagesync@ietfa.amsl.com>; Sat, 12 Dec 2015 05:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_BASE64_BLANKS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjdTx4pP_AA5 for <storagesync@ietfa.amsl.com>; Sat, 12 Dec 2015 05:48:15 -0800 (PST)
Received: from bjtu.edu.cn (mail.bjtu.edu.cn [218.249.29.198]) by ietfa.amsl.com (Postfix) with ESMTP id 058071A877D for <storagesync@ietf.org>; Sat, 12 Dec 2015 05:48:14 -0800 (PST)
Received: from PC-201001061KKK (unknown [211.71.74.217]) by Jdweb1 (Coremail) with SMTP id Mp5wygAX7nAkJmxWujcEAA--.11067S2; Sat, 12 Dec 2015 21:50:28 +0800 (CST)
Date: Sat, 12 Dec 2015 21:48:29 +0800
From: Fei Song <fsong@bjtu.edu.cn>
To: mellon <mellon@fugue.com>, storagesync <storagesync@ietf.org>
References: <1449452139832-4f314827-a7ecd596-c5312339@fugue.com> <1449454580239-1fd59d90-52f0231b-370f2ef5@gmail.com, > <1449455245871-cb7e86e1-1a0160c5-aa6acce3@fugue.com> <2015120711170621874681@bjtu.edu.cn> <1449459616112-6043cb32-cd69a1f9-1399f1c0@fugue.com> <CAO_Yprbct8wFbS1WFnZZENSp-OruRUk2nRyBv4tNeKv9_CGuCg@mail.gmail.com> <1449511062426-94cdee34-064ef498-327458b6@fugue.com> <CAO_YprZjqs_OFC3RybVvJ4GHWb3spKMMkkFTZO=YDustp825iw@mail.gmail.com> <1449593642163-c107ebb4-0f6d1c5a-a3f1c5e0@fugue.com> <20151208185922.GA9531@localhost.localdomain> <1449609937865-6dbdad8f-eb44d945-cd684f34@fugue.com> <AE0CE9F1-3968-4229-925B-75AA37EDC327@unterwaditzer.net> <1449670262769-e440b1e3-b960232c-260b9165@fugue.com> <506D291C-4F0B-40F3-8848-97DAAF41CAAE@cern.ch> <1449671733322-9f72a594-b1d5700c-d3631253@fugue.com> <56689982.3040901@owncloud.com>, <1449698718120-5228f72d-575bb833-81b4c859@fugue.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.91[cn]
Mime-Version: 1.0
Message-ID: <2015121221482912563828@bjtu.edu.cn>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
X-CM-TRANSID: Mp5wygAX7nAkJmxWujcEAA--.11067S2
X-Coremail-Antispam: 1UD129KBjvJXoW7uryxZr1DAw4fZw4rZF1kKrg_yoW8tw1DpF W3K3W3Kr4qvr1rAr1xJw1Ig3WFy3yktr15Zw15Kr15A3y5XryxXF4qgw4jkFZ5u395uFyF qFZaqwnru3s0vaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBqb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0 F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Xr4l42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWU GVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI 0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0 rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r 1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU8Za9DUUUUU==
X-CM-SenderInfo: aytwlqpemw3hxhgxhubq/
Archived-At: <http://mailarchive.ietf.org/arch/msg/storagesync/wb4DH7mnPzCm1M4RGIKwmV4wF_Y>
Subject: Re: [Storagesync] Storagesync Digest, Vol 5, Issue 1
X-BeenThere: storagesync@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: fsong <fsong@bjtu.edu.cn>
List-Id: Mechanisms to synchronize client file systems with Internet-based data storage services <storagesync.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storagesync>, <mailto:storagesync-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/storagesync/>
List-Post: <mailto:storagesync@ietf.org>
List-Help: <mailto:storagesync-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storagesync>, <mailto:storagesync-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Dec 2015 13:48:17 -0000



--------------
Fei Song
>Wednesday, Dec 9, 2015 4:13 PM Klaas Freitag wrote:
>> 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.
>
>I agree, as I said to Marc.   But the sync protocol has to _support_ the accurate detection of conflicts, or there's no way to resolve them, because you don't know about them (until your change has been overwritten, at which point it's too late).

+1
>
>> 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.
>
>Yes, I think we all agree that this is a problem.   Marc mentioned that he thinks it's a research problem.   I think a general solution is a research problem, and not a very interesting one: all I really want is a way to know that the conflict exists and what the sequence of events was; if an automatic merge is possible, that's great, but not required.
>
>> 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.
>
>Not remembering the order in which the changes occurred is an optimization which gains you almost no efficiency and costs you greatly in terms of functionality.

The order of changes is significant for some cases. In my routine work, e.g. source code, latex file, etc. just belong to these cases.

>
>> 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...
>
>Etags are sufficient if you just want to see if what you have is more recent in time than what's on the server.   They don't allow you to detect interleaved updates.
>
>
>--
>Sent from Whiteout Mail - https://whiteout.io
>
>My PGP key: https://keys.whiteout.io/mellon@fugue.com