thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.22_rc0 2015-09-23T11:03:34Z 2015-09-23T11:03:34Z David Bremner david@tethera.net 2015-09-06T13:15:47Z urn:sha1:6cdd34a4c762c954426f586d514a3e041c1db3b0 I think it would be no real problem to cut and paste the gdb based error message test from count to the other clients modified here, but I'm not currently convinced it's worth the trouble since the code path being tested is almost the the same, and the tests are relatively heavyweight. 2015-08-14T16:23:49Z David Bremner david@tethera.net 2015-04-05T22:39:55Z urn:sha1:f76d8f82dd004cf14426a91e8a80dcd2a4b97317 The function notmuch_exit_if_unmatched_db_uuid is split from notmuch_process_shared_options because it needs an open notmuch database. There are two exceptional cases in uuid handling. 1) notmuch config and notmuch setup don't currently open the database, so it doesn't make sense to check the UUID. 2) notmuch compact opens the database inside the library, so we either need to open the database just to check uuid, or change the API. 2015-06-01T05:32:54Z David Bremner david@tethera.net 2015-04-05T13:13:03Z urn:sha1:0018a8d787a98f80c665061daa9b0c73839d3666 Unfortunately it seems trickier to support --config globally The non-trivial changes are in notmuch.c; most of the other changes consists of blindly inserting two lines into every subcommand. 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.