thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.20.2 2014-07-16T22:33:10Z 2014-07-16T22:33:10Z Mark Walters markwalters1009@gmail.com 2014-06-23T20:12:29Z urn:sha1:bbbdf0478ea6109afc1ca5a26a8d1cd86b600e2a Dump currently only takes the read lock. Xapian can cope with some changes while maintaining a read snapshot but with more changes it fails. Currently notmuch just gives a xapian error. To avoid this we take the write lock when dumping. This prevents other notmuch processes from modifying the xapian database preventing this error. Discussion with Olly on irc indicates that this is currently the best solution: in xapian trunk there may be better possibilities using snapshots but they need to make it to a release and propogate out to users before we can switch approach. Finally, this breaks one use case: pipelines of the form notmuch dump | ... | notmuch restore According to Olly this is already very fragile: it will only work on small databases. One of the tests relies on this behaviour so fix that to store the dump rather than use a pipe. 2014-05-17T21:31:15Z David Bremner david@tethera.net 2014-05-08T11:57:07Z urn:sha1:f3ee655b493c7e57621226a98abc9e9db5d0cb27 Since the file size will have changed, there is no performance benefit to calling fdatasync. Somewhat surprisingly, using fdatasync apparently causes portability problems on FreeBSD. 2014-04-12T10:59:44Z David Bremner david@tethera.net 2014-03-29T01:14:51Z urn:sha1:3c13bc0321baaf340663779d6fce2b1f34c1c2c3 The main goal is to support gzipped output for future internal calls (e.g. from notmuch-new) to notmuch_database_dump. The additional dependency is not very heavy since xapian already pulls in zlib. We want the dump to be "atomic", in the sense that after running the dump file is either present and complete, or not present. This avoids certain classes of mishaps involving overwriting a good backup with a bad or partial one. 2014-03-30T22:23:16Z Jani Nikula jani@nikula.org 2014-03-25T17:48:57Z urn:sha1:3863755f6d9f3e7666c1484822384c036a4426c3 Also expose the dump function to the rest of notmuch. No functional changes, except for slight improvement in error handling. 2014-03-30T22:22:21Z Jani Nikula jani@nikula.org 2014-03-25T17:07:49Z urn:sha1:2a79d81211664ca3f0cd1a847795d48bd66b8a3d No functional changes, except for slight improvement in error handling. 2014-01-24T12:52:09Z David Bremner david@tethera.net 2014-01-23T13:02:46Z urn:sha1:f4167e6de86d071cd94721c2acc1397bf291a13c Although we didn't formally deprecate the old format, the new one has been available for a year. 2014-01-18T18:45:26Z Jani Nikula jani@nikula.org 2014-01-10T21:28:53Z urn:sha1:c7453773064efbd0b2cd17b15ba483edbd28ce1e Apart from the status codes for format mismatches, the non-zero exit status codes have been arbitrary. Make the cli consistently return either EXIT_SUCCESS or EXIT_FAILURE. 2013-03-08T11:54:41Z Jani Nikula jani@nikula.org 2013-03-03T21:55:09Z urn:sha1:4ef2106792439f5ade157b3ba3b8f7fa86fcb3ed This allows specifying config file as a top level argument to notmuch, and generally makes it possible to override config file options in main(), without having to touch the subcommands. If the config file does not exist, one will be created for the notmuch main command and setup and help subcommands. Help is special in this regard; the config is created just to avoid errors about missing config, but it will not be saved. This also makes notmuch config the talloc context for subcommands. 2013-03-07T13:39:12Z Jani Nikula jani@nikula.org 2013-03-03T21:55:08Z urn:sha1:e76f6517de020783d828be59f461f1d4f465c4b4 We now have a notmuch_config_is_new() function to query whether a config was created or not. Change the notmuch_config_open() is_new parameter into boolean create_new to determine whether the function should create a new config if one doesn't exist. This reduces the complexity of the API. 2013-01-07T02:40:32Z Austin Clements amdragon@MIT.EDU 2013-01-06T20:22:41Z urn:sha1:425e2bc81263230df301c67d93c64ff9685ff840 This switches the new batch-tag format away from using a home-grown hex-encoding scheme for message IDs in the dump to simply using Xapian queries with Xapian quoting syntax. This has a variety of advantages beyond presenting a cleaner and more consistent interface. Foremost is that it will dramatically simplify the quoting for batch tagging, which shares the same input format. While the hex-encoding is no better or worse for the simple ID queries used by dump/restore, it becomes onerous for general-purpose queries used in batch tagging. It also better handles strange cases like "id:foo and bar", since this is no longer syntactically valid.