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