thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=debian%2Fstretch 2016-09-21T21:14:24Z 2016-09-21T21:14:24Z David Bremner david@tethera.net 2016-06-13T01:05:51Z urn:sha1:b846bdb48233c907d1ecaff495fbf6bc578910d6 Support for prefix based iterators is perhaps overengineering, but I wanted to mimic the existing database_config API. 2016-09-21T21:14:24Z David Bremner david@tethera.net 2016-06-13T01:05:49Z urn:sha1:8b03ee1d5a310f82718281362d105ff09e30148f The choice of array implementation is deliberate, for future iterator support 2016-09-21T21:14:24Z David Bremner david@tethera.net 2016-06-13T01:05:48Z urn:sha1:4dfb69169e6b685670ebdeedab898c31adc995b2 This is a first step towards providing an API to attach arbitrary (key,value) pairs to messages and retrieve all of the values for a given key. 2016-08-09T00:34:11Z David Bremner david@tethera.net 2016-07-15T10:25:41Z urn:sha1:293186d6c6b1c4d158413de5412e6b4345e94970 _notmuch_database_log clears the log buffer each time. Rather than introducing more complicated semantics about for this function, provide a second function that does not clear the buffer. This is mainly a convenience function for callers constructing complex or multi-line log messages. The changes to query.cc are to make sure that the common code path of the new function is tested. 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-06-05T11:23:28Z Tomi Ollila tomi.ollila@iki.fi 2016-05-28T17:45:31Z urn:sha1:cf09631a45d276826255d197c1d5c913a29c79f4 Cleaned the following whitespace in lib/* files: lib/index.cc: 1 line: trailing whitespace lib/database.cc 5 lines: 8 spaces at the beginning of line lib/notmuch-private.h: 4 lines: 8 spaces at the beginning of line lib/message.cc: 1 line: trailing whitespace lib/sha1.c: 1 line: empty lines at the end of file lib/query.cc: 2 lines: 8 spaces at the beginning of line lib/gen-version-script.sh: 1 line: trailing whitespace 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:49Z urn:sha1:011fc41d4d1a1dc9ae3765c9f08ee603eea7bc7e Publicly we are only exposing the non-ghost documents (of "type" "mail"). But internally we might want to inspect the ghost messages as well. This changeset adds two new private interfaces to queries to recover information about alternate document types. 2015-09-07T12:43:31Z Jani Nikula jani@nikula.org 2015-09-03T19:40:01Z urn:sha1:f460ad4e9a2516b05162cc57c2d3b0e8b814b0c2 For future use in both cli and lib. 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.