--- /dev/null
+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 272C06DE17DB\r
+ for <notmuch@notmuchmail.org>; Mon, 10 Aug 2015 04:34:20 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.132\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[AWL=0.132]\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 gK23qlM23GAR for <notmuch@notmuchmail.org>;\r
+ Mon, 10 Aug 2015 04:34:18 -0700 (PDT)\r
+Received: from gitolite.debian.net (gitolite.debian.net [87.98.215.224])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id 249506DE00DE\r
+ for <notmuch@notmuchmail.org>; Mon, 10 Aug 2015 04:34:17 -0700 (PDT)\r
+Received: from remotemail by gitolite.debian.net with local (Exim 4.80)\r
+ (envelope-from <david@tethera.net>)\r
+ id 1ZOlJx-0002jN-Q4; Mon, 10 Aug 2015 11:32:49 +0000\r
+Received: (nullmailer pid 29862 invoked by uid 1000); Mon, 10 Aug 2015\r
+ 11:32:40 -0000\r
+From: David Bremner <david@tethera.net>\r
+To: Daniel Schoepe <daniel@schoepe.org>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 4/5] cli: add global option "--uuid"\r
+In-Reply-To: <87fv3rtray.fsf@schoepe.localhost>\r
+References: <1439112285-6681-1-git-send-email-david@tethera.net>\r
+ <1439112285-6681-5-git-send-email-david@tethera.net>\r
+ <87fv3rtray.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: Mon, 10 Aug 2015 13:32:40 +0200\r
+Message-ID: <87r3nbl6p3.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: Mon, 10 Aug 2015 11:34:20 -0000\r
+\r
+Daniel Schoepe <daniel@schoepe.org> writes:\r
+\r
+> Based on quick experiments, it seems that the revisions don't change\r
+> when compacting the database; is this something that the patches\r
+> guarantee or a coincidence?\r
+\r
+Now that you mention it, I can see that despite essentially quoting the\r
+xapian docs, compacting might not be the best example.\r
+\r
+According to the xapian docs:\r
+\r
+ The UUID will persist for the lifetime of the database.\r
+\r
+ Replicas (eg, made with the replication protocol, or by copying all\r
+ the database files) will have the same UUID. However, copies (made\r
+ with copydatabase, or xapian-compact) will have different UUIDs.\r
+\r
+So compacting is in fact a bit of a strange case, it preserves the\r
+lastmod counters (because those are just terms on documents), but not\r
+the uuid. This means from notmuch point of view have no programmatic way\r
+to know that we can trust the lastmod data, i.e. no way to distinguish a\r
+previous notmuch-compact from "notmuch dump && rm the database &&\r
+notmuch new && notmuch restore". On the other hand, I _think_ we could\r
+promise the user that lastmod data is preserved by compacting; they\r
+would just have to tell whatever external tool to ignore uuid errors and\r
+perhaps set the new uuid.\r
+\r
+d\r