Re: [PATCH 3/5] cli/count: add --lastmod

diff --git a/0c/2eb7a166417077474ec643b63e4885e90aadf8 b/0c/2eb7a166417077474ec643b63e4885e90aadf8
new file mode 100644 (file)
index 0000000..01394f1
--- /dev/null
+++ b/0c/2eb7a166417077474ec643b63e4885e90aadf8
@@ -0,0 +1,88 @@
+Return-Path: <david@tethera.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 arlo.cworth.org (Postfix) with ESMTP id 69DDE6DE192C\r
+ for <notmuch@notmuchmail.org>; Sat, 15 Aug 2015 03:44:11 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.127\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=0.127]\r
+ autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id BDWBVoSzGOxj for <notmuch@notmuchmail.org>;\r
+ Sat, 15 Aug 2015 03:44:09 -0700 (PDT)\r
+Received: from gitolite.debian.net (gitolite.debian.net [87.98.215.224])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id 249406DE17D7\r
+ for <notmuch@notmuchmail.org>; Sat, 15 Aug 2015 03:44:08 -0700 (PDT)\r
+Received: from remotemail by gitolite.debian.net with local (Exim 4.80)\r
+ (envelope-from <david@tethera.net>)\r
+ id 1ZQYvA-0006kx-Ej; Sat, 15 Aug 2015 10:42:40 +0000\r
+Received: (nullmailer pid 20981 invoked by uid 1000); Sat, 15 Aug 2015\r
+ 10:42:31 -0000\r
+From: David Bremner <david@tethera.net>\r
+To: Daniel Schoepe <daniel@schoepe.org>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 3/5] cli/count: add --lastmod\r
+In-Reply-To: <878u9dyq2a.fsf@schoepe.localhost>\r
+References: <1439570878-15165-1-git-send-email-david@tethera.net>\r
+ <1439570878-15165-4-git-send-email-david@tethera.net>\r
+ <878u9dyq2a.fsf@schoepe.localhost>\r
+User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sat, 15 Aug 2015 12:42:31 +0200\r
+Message-ID: <87si7kx27c.fsf@maritornes.cs.unb.ca>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.18\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: Sat, 15 Aug 2015 10:44:11 -0000\r
+\r
+Daniel Schoepe <daniel@schoepe.org> writes:\r
+\r
+> Sorry to keep harping on this, but I'm not entirely happy with the way\r
+> we handle notmuch-compact here (and in the other commit that mentions\r
+> compacting explicitly). Given that lastmod values (and pretty much\r
+> everything else) aren't affected by compacting, would it perhaps make\r
+> sense to copy the previous UUID to the newly compacted database?\r
+\r
+We aren't currently maintaining a UUID for notmuch, but using\r
+Xapian::database::get_uuid(). There is no way in Xapian to change the\r
+UUID; even if there was, lying to Xapian probably would not be a good\r
+idea.\r
+\r
+We could maintain our own UUID, but I'm not sure it's worth the extra\r
+code just to make compaction slightly nicer. \r
+\r
+For me compaction is a rare event, so having to take the fallback path\r
+and do a full dump or whatever doesn't seem so bad. If you don't want to\r
+have a fallback path, then I guess you need to guarantee externally that\r
+no "bad changes" happen and either ignore the uuid's or copy them\r
+forward in your external tool.\r
+\r
+Mainly though I think this will be fixed in Xapian. As it happens Xapian\r
+developer Olly Betts is here at DebConf, and I discussed this problem\r
+with him. According to Olly, in-progress / future versions of compact\r
+will function in place, and guarantee the UUID is preserved. I'm not\r
+sure of the timeline here, but given our scarce developer resources, I\r
+think I'd rather wait for Olly to fix this.\r
+\r
+On the bright side, if in the future we decide that notmuch should have\r
+it's own notion of UUID, then this would would not change the library\r
+API or command line interface.  There is some argument here for giving\r
+our name to the UUID, but "revision" turned out to be a terribly\r
+confusing choice in previous rounds of patches.  The current transparent\r
+naming has the advantage of matching the output.\r
+\r
+d\r