Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 558E040BDA7 for ; Tue, 5 Oct 2010 13:50:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_SORBS_WEB=0.77] autolearn=no Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCU9Is+hnudW for ; Tue, 5 Oct 2010 13:50:45 -0700 (PDT) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.113.126.25]) by olra.theworths.org (Postfix) with ESMTP id EE0DF40BC9C for ; Tue, 5 Oct 2010 13:50:44 -0700 (PDT) X-Hash: SCtCte|417cd1b7cc8c75c1c0ee09bd4b9764fe911ab1fa|537afd2fd94b7f5ab7e76d1dfaa0472b X-Countries: Cameroon, United States X-SMTP-From: accepted [195.24.209.14] [195.24.209.14] ([10.0.9.177]) {Cameroon} DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cs.rpi.edu; h= message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=default; i=glasse@cs.rpi.edu; t= 1286311844; x=1286916644; l=1890; bh=woOjtN7Fry9OpONtY6I8wxyEymI =; b=LqZN11MBS1euQrwh1K+pXtAyApB2n7QJTxqAjOIsdVvcbhO/yecUIbPGVC6 BH71eA01kDJL1E4rZPnJB6MxcMqVat9kY2a7cfsxjZE95mWrev/mlmJbCdAeoOi/ tHsg9DKTL0Kx844n8MAMQB8HTHQrqheV6JlTWS4Ydd9MwV6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cs.rpi.edu; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=default; b=ruz/Egvug30Cfsh9 eT78f/rqQxP8fE6pN8jETDe5+YAF7+IkzKz+K5lvCN14LEwniH33Kk/fT1e6IoYb VBpjLcTgodGwbXJeIpjqh8B5R0Vp2SO0UtmCP/gZCBT+nflwgFhIlLtalPh4Nd7T I6A7zfH94YO5wNShEmJTQ4MMjaI= X-Spam-Info: -2.5; ALL_TRUSTED,AWL,BAYES_00 X-Spam-Scanned-By: cliffclavin.cs.rpi.edu using SpamAssassin 3.2.5 (hard limit 15) Authentication-Results: cliffclavin.cs.rpi.edu; DKIM=neutral (none) header.from=glasse@cs.rpi.edu; SPF=neutral (mfrom; Mechanism '?all' matched) smtp.mail=glasse@cs.rpi.edu X-Auth-Passed: cliffclavin.cs.rpi.edu:o95KnfbI058860 Auth:glasse X-Virus-Scanned-By: cliffclavin.cs.rpi.edu Received: from [10.0.9.177] ([195.24.209.14]) (authenticated bits=0) by cliffclavin.cs.rpi.edu (8.14.3/8.14.3) with ESMTP id o95KnfbI058860 for ; Tue, 5 Oct 2010 16:50:26 -0400 (EDT) (envelope-from glasse@cs.rpi.edu) Message-ID: <4CAB8F24.7060300@cs.rpi.edu> Date: Tue, 05 Oct 2010 16:48:36 -0400 From: Ethan Glasser-Camp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: notmuch@notmuchmail.org Subject: notmuch synchronization Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.113.126.25 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 20:50:55 -0000 I recently got interested in notmuch again and I wanted to see what the current situation is with regard to synchronization -- specifically multiple machines each running notmuch, but also notmuch with other non-notmuch clients. As far as I can tell, this is "possible" but not easy or clean: - the message at http://notmuchmail.org/pipermail/notmuch/2010/002957.html starts a thread about exactly this subject. This seems like the most promising approach (using unison to sync mail across all machines, and using notmuch dump and notmuch restore to propagate the tag database), but I'm a little scared by the note that: > Well, only one place where you mark things unread as well with this > approach. Otherwise updating the database in two places and attempting > to sync will lead to an unmergable conflict, won't it? But if I'm understanding things correctly, it should be OK if you mark unread one place, notmuch dump, restore in the second place, and then mark something else unread, right? Otherwise you don't have true disconnected operation, which seems to be to lose tho whole point. - There's a large number of patches from Michal Sojka, the latest from April 2010, about an abstract mailstore interface, towards using Git as an object store; Git has really nice distributed properties, in that each clone offers fully disconnected operation, and that you can sync any one against any other one, so something like that sounds pretty awesome. Unfortunately, Michal wrote that "I do not want this to be merged yet, but there might be some people interested in testing this.". Is there any news with these patches? Are they something that could potentially be merged? At a high level, what kind of behavior do they implement? (The most recent thread on this subject was at: http://notmuchmail.org/pipermail/notmuch/2010/002119.html) Ethan