Re: [PATCH 0/5] Store message modification times in the DB

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