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