From: David Bremner <david@tethera.net>
To: Daniel Schoepe <daniel@schoepe.org>, 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
Precedence: list

Daniel Schoepe <daniel@schoepe.org> 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