thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.23.6 2016-06-05T11:32:17Z 2016-06-05T11:32:17Z Daniel Kahn Gillmor dkg@fifthhorseman.net 2016-06-02T16:26:14Z urn:sha1:6a833a6e83865f6999707cc30768d07e1351c2cb Many of the external links found in the notmuch source can be resolved using https instead of http. This changeset addresses as many as i could find, without touching the e-mail corpus or expected outputs found in tests. 2016-05-25T10:40:44Z David Bremner david@tethera.net 2016-03-22T10:54:54Z urn:sha1:b9bf3f44eacd42ce53885c79f9dad8d82c76f13d This relies on the optional presense of xapian field processors, and the library config API. 2016-05-25T10:40:44Z David Bremner david@tethera.net 2016-03-22T10:54:53Z urn:sha1:30caaf52b022be5f0f695f3088286fb56e82c782 It's already kindof gross that this is hardcoded in two different places. We will also need these later in field processors calling back into the query parser. 2016-05-08T11:17:07Z David Bremner david@tethera.net 2016-03-22T10:54:44Z urn:sha1:bbf6069252d31e6693ee99cce8bf4f9fab47e360 This relies on the FieldProcessor API, which is only present in xapian >= 1.3. 2015-08-14T16:23:49Z Austin Clements amdragon@mit.edu 2014-10-13T06:20:03Z urn:sha1:cb08a2ee019e52dc29ba393d139fce8d7282c632 The implementation is essentially the same as the date range search prior to Jani's fancy date parser. 2015-08-13T21:52:51Z Austin Clements aclements@csail.mit.edu 2014-10-13T06:20:02Z urn:sha1:98ee460eaa98f1428aecf03dd39fcf314e6f62c0 This exposes the committed database revision to library users along with a UUID that can be used to detect when revision numbers are no longer comparable (e.g., because the database has been replaced). 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-03-28T23:34:15Z David Bremner david@tethera.net 2014-12-26T08:01:01Z urn:sha1:b53e1a2da720e9a0efd815b92f0a54dc2f644ffc In principle in the future this could do something fancier than asprintf. 2015-01-24T15:47:47Z Todd todd@electricoding.com 2015-01-22T23:43:37Z urn:sha1:0de999aab5bd4cd44bc4ea76fd1d25172bd839ae This feature will exist in all newly created databases, but there is no upgrade provided for it. If this flag exists, it indicates that the database was created after the indexed MIME-types feature was added. 2014-10-25T17:31:27Z Austin Clements amdragon@mit.edu 2014-10-23T12:30:39Z urn:sha1:ee476f1e7616fa53c492b8077b55af35662eec82 This fixes the broken thread order test.