I should add that this code shouldn't be considered stable yet. The on-disk format may (and probably will) change, so don't try it on your main notmuch database.
Quoth myself on Aug 01 at 2:55 pm: > I have a prototype implementation of message modification times on my > lastmod-v1 branch at > > https://github.com/aclements/notmuch/tree/lastmod-v1 > > It builds on my database features series that's currently awaiting > review [1]. > > The series uses a monotonic revision number, rather than wall-clock > time, for reasons related to Xapian's concurrent control and detailed > in the main commit's commit message. The implementation isn't quite > useful from the CLI yet because I haven't added any way to query the > database's current revision number. (I'm still thinking about how I > want to do this, since search/show don't have a good way to deliver > "additional" information right now. I might just add the last > modification for each individual message/max of all messages in a > thread, similar to what Thomas Jost's patch did long ago.) > > [1] id:1406859003-11561-1-git-send-email-amdragon at mit.edu > > Quoth Gaute Hope on Jul 28 at 4:37 pm: > > On Thu, Jul 3, 2014 at 12:42 PM, David Bremner <[1]david at tethera.net> > > wrote: > > > > Gaute Hope <[2]eg at gaute.vetsj.com> writes: > > > > > When one of the source files for a message is changed on disk, > > renamed, > > > deleted or a new source file is added. A configurable changed tag is > > > is added. The tag can be configured under the option 'changed_tags' > > in > > > the [new] section, the default is none. Tests have been updated to > > > accept the new config option. > > > > > > notmuch-setup now asks for a changed tag after the new tags question. > > > > > > This could be useful for for example 'afew' to detect remote changes > > in > > > IMAP folders and update the FolderNameFilter to also add tags or > > remove > > > tags when a _existing_ message has been added to or removed from a > > > maildir. > > > > The discussion on this proposal seems to have died out without reaching > > a conclusion. David M expressed a strong preference for some kind of > > modification time field in the database. ?Gaute agreed with some > > caveats > > that such an approach could solve his problems as well. On the other > > hand, nobody seems to be actually working on such an approach at the > > moment. ?Gaute and or David do you have any interest in revisiting the > > series [3]id:1323796305-28789-1-git-send-email-schnouki at > > schnouki.net and > > seeing if it can be reworked into mergeable shape? I suspect in > > particular something needs to be added with respect to message deletion > > Thomas, are you still running some variant of these patches? > > d > > > > I am afraid I don't have the chance to put in any consistent effort on > > this at the moment. > > > > I agree, message deletion needs to be solved somehow. > > Regards, Gaute -- Austin Clements MIT/CSAIL/SB '06/PhD '14 amdragon at mit.edu http://web.mit.edu/amdragon Somewhere in the dream we call reality you will find me, searching for the reality we call dreams.
