unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
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"
Date: Mon, 10 Aug 2015 13:32:40 +0200	[thread overview]
Message-ID: <87r3nbl6p3.fsf@maritornes.cs.unb.ca> (raw)
In-Reply-To: <87fv3rtray.fsf@schoepe.localhost>

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

  reply	other threads:[~2015-08-10 11:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-09  9:24 revisision tracking patches round 3 David Bremner
2015-08-09  9:24 ` [PATCH 1/5] lib: Add per-message last modification tracking David Bremner
2015-08-09  9:24 ` [PATCH 2/5] lib: API to retrieve database revision and UUID David Bremner
2015-08-09  9:24 ` [PATCH 3/5] cli/count: add --output=modifications David Bremner
2015-08-10 19:28   ` Tomi Ollila
2015-08-11 18:45     ` David Bremner
2015-08-11 20:13       ` Tomi Ollila
2015-08-12  9:38         ` David Bremner
2015-08-12 12:33           ` Daniel Schoepe
2015-08-09  9:24 ` [PATCH 4/5] cli: add global option "--uuid" David Bremner
2015-08-10  9:40   ` Daniel Schoepe
2015-08-10 11:32     ` David Bremner [this message]
2015-08-10 12:57       ` Daniel Schoepe
2015-08-10 19:42   ` Tomi Ollila
2015-08-09  9:24 ` [PATCH 5/5] lib: Add "lastmod:" queries for filtering by last modification David Bremner
  -- strict thread matches above, loose matches on Subject: below --
2015-08-14 16:47 revision tracking patches round 4 David Bremner
2015-08-14 16:47 ` [PATCH 4/5] cli: add global option "--uuid" David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r3nbl6p3.fsf@maritornes.cs.unb.ca \
    --to=david@tethera.net \
    --cc=daniel@schoepe.org \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).