[PATCH] Add configurable changed tag to messages that have been changed on disk
Austin Clements
amdragon at MIT.EDU
Fri Aug 1 11:55:05 PDT 2014
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
More information about the notmuch
mailing list