thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.23_rc0 2016-09-21T21:14:25Z 2016-09-21T21:14:25Z David Bremner david@tethera.net 2016-06-13T01:05:54Z urn:sha1:b7345d277ec5f562000c0e740e6515c2a84f9c76 Part of providing extensibility via properties is to make sure that user data is not lost. Thus we need to be able to dump and restore properties. 2016-09-21T21:14:25Z David Bremner david@tethera.net 2016-06-13T01:05:53Z urn:sha1:f240528095169bf45a88e6790fd6b546cc8f48c5 This is mainly code movement, to make room in the loop over messages for dumping properties. 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:07:56Z David Bremner david@tethera.net 2016-03-22T10:54:50Z urn:sha1:e042a25a3fd8706b6e1ee7bdf527bb17ecb74c6a Note that it changes the default dump output format, but doesn't break existing notmuch-restore. It might break user scripts though. 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.