From: Daniel Schoepe <daniel@schoepe.org>
To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org
Subject: Re: [PATCH 4/5] cli: add global option "--uuid"
In-Reply-To: <87r3nbl6p3.fsf@maritornes.cs.unb.ca>
References: <1439112285-6681-1-git-send-email-david@tethera.net>
 <1439112285-6681-5-git-send-email-david@tethera.net>
 <87fv3rtray.fsf@schoepe.localhost> <87r3nbl6p3.fsf@maritornes.cs.unb.ca>
User-Agent: Notmuch/0.20.2+58~g20ed908 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-unknown-linux-gnu)
Date: Mon, 10 Aug 2015 14:57:42 +0200
Message-ID: <87d1yvti61.fsf@schoepe.localhost>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Mon, 10 Aug 2015 13:32 +0200, David Bremner wrote:
> 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.

Yeah, I think it's reasonable to assume that if the user will delete and
recreate the database, they will also perform the necessary
reinitialization of whatever tool makes use of lastmod / UUID. I guess
this also means that tools often only care about lastmod values and not
the UUID, to allow for compacting without thinking the database is
completely different now.

Another option is to include lastmod values in the output of
notmuch-dump. Doing that in a clean way might be hard though and I think
this shouldn't be part of this series (which looks fine to me now).

Best regards,
Daniel