thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.10 2011-10-22T22:42:54Z 2011-10-22T22:42:54Z David Bremner bremner@debian.org 2011-10-21T12:19:17Z urn:sha1:61f0a5b8ee2adf540106a09c5f83fe634da6beb3 previously we deleted the subcommand name from argv before passing to the subcommand. In this version, the deletion is done in the actual subcommands. Although this causes some duplication of code, it allows us to be more flexible about how we parse command line arguments in the subcommand, including possibly using off-the-shelf routines like getopt_long that expect the name of the command in argv[0]. 2011-10-04T04:55:29Z Ali Polatel alip@exherbo.org 2011-10-04T04:55:29Z urn:sha1:02a30767116ad8abcbd0a3351f2e4d43bbbd655f Previously, the functions notmuch_database_find_message() and notmuch_database_find_message_by_filename() functions did not properly report error condition to the library user. For more information, read the thread on the notmuch mailing list starting with my mail "id:871uv2unfd.fsf@gmail.com" Make these functions accept a pointer to 'notmuch_message_t' as argument and return notmuch_status_t which may be used to check for any error condition. restore: Modify for the new notmuch_database_find_message() new: Modify for the new notmuch_database_find_message_by_filename() 2011-09-24T23:00:29Z Austin Clements amdragon@mit.edu 2011-01-29T16:25:56Z urn:sha1:bff30540d86c77aacbc2c133c83aa7ccee823b48 This addresses atomicity of tag synchronization, the last atomicity problems in notmuch new. Each message add or remove is wrapped in its own atomic section, so interrupting notmuch new doesn't lose progress. 2011-09-24T23:00:28Z Austin Clements amdragon@mit.edu 2011-01-28T01:51:04Z urn:sha1:8305f0aac7f31aeddd54d0af683475ab1492e2b7 Because flag synchronization is stateless, it can be performed at any time as long as it's guaranteed to be performed after any change to a message's filename list. Take advantage of this to synchronize tags immediately after a filename is added or removed. This does not yet make adding or removing a message atomic, but it is a big step toward atomicity because it reduces the window where the database tags are inconsistent from nearly the entire notmuch-new to just around when the message is added or removed. 2011-09-24T23:00:28Z Austin Clements amdragon@mit.edu 2011-02-06T09:28:01Z urn:sha1:191c4ae693c35ecd9e905e64c7619734171c4a8a Previously, file name removal was implemented identically in two places. Now it's captured in one function. This is important because file name removal is about to get slightly more complicated with eager tag synchronization and correct removal atomicity. 2011-09-24T23:00:28Z Austin Clements amdragon@mit.edu 2011-06-11T16:54:05Z urn:sha1:1353dbe8642ebf5fc7e4ff562bb4b8f3a8e15132 Previously, pointers to these variables were passed around individually. This was okay when only one function needed them, but we're about to need them in a few more places. 2011-09-24T01:50:38Z Austin Clements amdragon@mit.edu 2011-06-11T03:35:06Z urn:sha1:e59cc0031fbf84f49e32dedb9927f427d2c49309 notmuch_database_t now keeps a nesting count and we only start a transaction or commit for the outermost atomic section. Introduces a new error, NOTMUCH_STATUS_UNBALANCED_ATOMIC. 2011-09-24T01:50:38Z Austin Clements amdragon@mit.edu 2011-02-08T23:24:33Z urn:sha1:fcd433709eff6b7f0fbbd1e5018ca0e37315ce26 Previously, if notmuch new were interrupted between updating the directory mtime and handling removals from that directory, a subsequent notmuch new would not handle those removals until something else changed in that directory. This defers recording the updated mtime until after removals are handled to eliminate this problem. 2011-09-14T01:00:15Z Austin Clements amdragon@mit.edu 2011-02-09T01:56:31Z urn:sha1:bdaee77e1b0853b0dab00565e4c5b6164248f85a Previously, message removals were always performed, even after a SIGINT. As a result, when a message was moved from one folder to another, a SIGINT between processing the directory the message was removed from and processing the directory it was added to would result in notmuch removing that message from the database. 2011-06-29T23:10:41Z Austin Clements amdragon@MIT.EDU 2011-06-29T23:00:01Z urn:sha1:bb2b33fbb85b88eb7d3bedf4cb261a89da20f504 Currently, notmuch new assumes any directory with a database mtime of 0 is new, but we don't set the mtime until after processing messages and subdirectories in that directory. Hence, anything that prevents the mtime update (such as an interruption or the wall-clock logic introduced in 8c39e8d6) will cause the next notmuch new to think the directory is still new. We work around this by setting the new directory's database mtime to -1 before scanning anything in the new directory. This also obviates the need for the workaround used in 8c39e8d6.