thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.9 2011-10-04T16:47:04Z 2011-10-04T16:47:04Z David Bremner bremner@debian.org 2011-10-04T16:47:04Z urn:sha1:9e976fc60c40e07cb62a7d656e86ee3101c1b2f5 Based on discussions with amdragon, tschwinge, and others on IRC, I concluded that 1) symbol versioning was probably overkill for libnotmuch 2) It was also probably GNU ld specific 3) Most importantly, nobody could tell me on short notice how exactly it works. So since the change to the notmuch_database_find_message breaks the previous ABI, we need to bump the SONAME. 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-10-04T04:39:57Z Ali Polatel alip@exherbo.org 2011-10-03T20:27:32Z urn:sha1:9b3f16ce715d2371224955bc5b6f948eaa4ee325 notmuch_database_remove_message() must call notmuch_message_destroy() once it is done handling message removal. 2011-09-24T23:26:42Z David Bremner bremner@debian.org 2011-09-24T19:13:49Z urn:sha1:0ce713ae02a2f2fc326d9c04bf9bf95123f228c0 This bump is because of the new symbols introduced by the atomicity patches. 2011-09-24T23:00:29Z Austin Clements amdragon@mit.edu 2011-06-11T19:34:11Z urn:sha1:35f4a0f18b2484e835e8b647f3d2c2782efcc406 State up front that these functions may add a filename to an existing message or remove only a filename (and not the message), respectively. Previously, this key information was buried in return value documentation or in "notes", which made it seem secondary to these functions' semantics. 2011-09-24T23:00:28Z Austin Clements amdragon@mit.edu 2011-06-11T04:42:58Z urn:sha1:51c3c0b2d27c8d0ba8e1ae242fd907c59f82d992 Adding a message may involve changes to multiple database documents, and thus needs to be done in a transaction. This makes add_message (and, I think, the whole library) atomicity-safe: library callers only needs to use atomic sections if they needs atomicity across multiple library calls. 2011-09-24T23:00:28Z Austin Clements amdragon@mit.edu 2011-06-11T04:19:31Z urn:sha1:7a8046ced8c0e61ddd0ff463cfc17ed63e6edad3 notmuch_database_find_message_by_filename is mostly stolen from notmuch_database_remove_message, so this patch also vastly simplfies the latter using the former. This API is also useful in its own right and will be used in a later patch for eager maildir flag synchronization. 2011-09-24T01:50:39Z Austin Clements amdragon@mit.edu 2011-06-11T04:07:54Z urn:sha1:bfe4555325086d5cb99e3962424128f94d1c921d Previously, notmuch_database_remove_message would remove the message file name, sync the change to the message document, re-find the message document, and then delete it if there were no more file names. An interruption after sync'ing would result in a file-name-less, permanently un-removable zombie message that would produce errors and odd results in searches. We could wrap this in an atomic section, but it's much simpler to eliminate the round-about approach and just delete the message document instead of sync'ing it if we removed the last filename. 2011-09-24T01:50:39Z Austin Clements amdragon@mit.edu 2011-02-06T09:17:49Z urn:sha1:e4379c43e21ff69dcdb66064fe3de83ae0642fc0 Make _notmuch_message_remove_filename return NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID if the message has more filenames and fix callers to handle this. 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.