thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.22.1 2016-04-15T10:13:49Z 2016-04-15T10:13:49Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-04-09T01:54:52Z urn:sha1:e366bb222722d6a635b736e875b760d82b46d1f5 To fully complete the ghost-on-removal-when-shared-thread-exists proposal, we need to clear all ghost messages when the last active message is removed from a thread. Amended by db: Remove the last test of T530, as it no longer makes sense if we are garbage collecting ghost messages. 2016-04-15T10:07:23Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-04-09T01:54:51Z urn:sha1:1695415039803fd3b317bccbb3ceca0472bed373 There is no need to add a ghost message upon deletion if there are no other active messages in the thread. Also, if the message being deleted was a ghost already, we can just go ahead and delete it. 2016-04-15T10:07:23Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-04-09T01:54:50Z urn:sha1:9eebae3da4510a671cbbb2f476c2dc04099b4415 It can be useful to easily tell if a given message has a given term associated with it. 2016-04-15T10:07:23Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-04-09T01:54:48Z urn:sha1:604d1e0977c2ede365f87492d6b9bf9a83c3e1d3 implement ghost-on-removal, the solution to T590-thread-breakage.sh that just adds a ghost message after removing each message. It leaks information about whether we've ever seen a given message id, but it's a fairly simple implementation. Note that _resolve_message_id_to_thread_id already introduces new message_ids to the database, so i think just searching for a given message ID may introduce the same metadata leakage. 2016-01-16T12:17:15Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-01-15T05:23:10Z urn:sha1:07b6220a5595bf4556e636709220121d6405e9e9 This is a nit-picky orthographical fix for an nit-picky ontological comment. 2016-01-16T12:16:51Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-01-15T19:02:38Z urn:sha1:e038b95ffe18b13fb47f4982ddc969669172cb32 notmuch_database_remove_message has no leading underscore in its name. 2015-08-13T21:52:51Z Austin Clements amdragon@mit.edu 2014-10-13T06:20:01Z urn:sha1:7f57b747b95eece465d10fd0acba20cc3dd868f1 This adds a new document value that stores the revision of the last modification to message metadata, where the revision number increases monotonically with each database commit. An alternative would be to store the wall-clock time of the last modification of each message. In principle this is simpler and has the advantage that any process can determine the current timestamp without support from libnotmuch. However, even assuming a computer's clock never goes backward and ignoring clock skew in networked environments, this has a fatal flaw. Xapian uses (optimistic) snapshot isolation, which means reads can be concurrent with writes. Given this, consider the following time line with a write and two read transactions: write |-X-A--------------| read 1 |---B---| read 2 |---| The write transaction modifies message X and records the wall-clock time of the modification at A. The writer hangs around for a while and later commits its change. Read 1 is concurrent with the write, so it doesn't see the change to X. It does some query and records the wall-clock time of its results at B. Transaction read 2 later starts after the write commits and queries for changes since wall-clock time B (say the reads are performing an incremental backup). Even though read 1 could not see the change to X, read 2 is told (correctly) that X has not changed since B, the time of the last read. In fact, X changed before wall-clock time A, but the change was not visible until *after* wall-clock time B, so read 2 misses the change to X. This is tricky to solve in full-blown snapshot isolation, but because Xapian serializes writes, we can use a simple, monotonically increasing database revision number. Furthermore, maintaining this revision number requires no more IO than a wall-clock time solution because Xapian already maintains statistics on the upper (and lower) bound of each value stream. 2015-08-04T06:54:46Z Austin Clements amdragon@mit.edu 2015-06-05T17:28:33Z urn:sha1:e6ad3a5dd4ca7a09a4760c4eb6721217cc906aaa Previously, we updated the database copy of a message on every call to _notmuch_message_sync, even if nothing had changed. In particular, this always happens on a thaw, so a freeze/thaw pair with no modifications between still caused a database update. We only modify message documents in a handful of places, so keep track of whether the document has been modified and only sync it when necessary. This will be particularly important when we add message revision tracking. 2015-03-28T23:34:15Z David Bremner david@tethera.net 2014-12-26T17:34:49Z urn:sha1:9d192da683b0656e37fc8d69c69698ca605926b3 You may wonder why _notmuch_message_file_open_ctx has two parameters. This is because we need sometime to use a ctx which is a notmuch_message_t. While we could get the database from this, there is no easy way in C to tell type we are getting. 2015-03-28T23:34:15Z David Bremner david@tethera.net 2014-12-26T16:25:35Z urn:sha1:736ac26407914425a9c94e86616225292cf716dd This is not supposed to change any functionality from an end user point of view. Note that it will eliminate some output to stderr. The query debugging output is left as is; it doesn't really fit with the current primitive logging model. The remaining "bad" fprintf will need an internal API change.