From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 76748431FD0 for ; Tue, 20 Dec 2011 07:23:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[DATE_IN_PAST_12_24=0.804] autolearn=disabled 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 FcEohHsB6WFR for ; Tue, 20 Dec 2011 07:23:43 -0800 (PST) Received: from socrates.hocat.ca (socrates.hocat.ca [76.10.188.53]) by olra.theworths.org (Postfix) with ESMTP id 3F5B6429E25 for ; Tue, 20 Dec 2011 07:23:43 -0800 (PST) Received: from me (ares.hocat.ca [76.10.189.33]) by socrates.hocat.ca (Postfix) with SMTP id 046571568; Tue, 20 Dec 2011 08:23:42 -0700 (MST) Received: (nullmailer pid 7197 invoked by uid 1000); Mon, 19 Dec 2011 22:56:39 -0000 From: Tom Prince To: Austin Clements , David Edmondson Subject: Re: [PATCH 0/5] Store message modification times in the DB In-Reply-To: <20111219194821.GA10376@mit.edu> References: <1323796305-28789-1-git-send-email-schnouki@schnouki.net> <20111219194821.GA10376@mit.edu> User-Agent: Notmuch/0.5-118-gdcdb843 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu) Date: Mon, 19 Dec 2011 15:56:39 -0700 Message-ID: <87r500cgrc.fsf@loki.hocat.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: notmuch@notmuchmail.org 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, 20 Dec 2011 15:23:44 -0000 On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements wrote: > This protocol requires significantly more state, but can also > reconstruct per-tag changes. Conflict resolution is equivalent to > what git would do and is based solely on the current local and remote > state and the common ancestor state. This seems like exactly what one would get if one stored the tag state in git, which seems like a reasonable thing to do anyway. > This can lead to unintuitive results if a tag on a message has gone > through multiple changes on both hosts since the last sync (though, I > argue, there are no intuitive results in such situations). I certainly agree that there isn't a universally good resolution to this. I suspect that the same person, making the same tag changes with the same mtimes, will want different resolutions at different times. This is because there is no good way to record the intent of the changes. > Tombstones are only required to garbage collect sync state (and other > techniques could be used for that). I wonder how many people using notmuch actually delete mail? I know I don't bother to, anymore. One use case that was mentioned, is having a limited amount of mail on a portable device, and syncing tags on those message present. Using git to record the tag state, one would just need to record the state before deleting files, to avoid the need for tombstones in the notmuch db. Tom