22. sep. 2014 17:40 skrev "Austin Clements"
følgende:
>
> On Mon, 22 Sep 2014, Gaute Hope wrote:
> > Excerpts from Gaute Hope's message of August 6, 2014 10:29:
> >> Austin Clements wrote on Fri, 01 Aug 2014 14:55:05
-0400:
> >>> I have a prototype implementation of message modification times on
On Mon, 22 Sep 2014, Gaute Hope wrote:
> Excerpts from Gaute Hope's message of August 6, 2014 10:29:
>> Austin Clements wrote on Fri, 01 Aug 2014 14:55:05 -0400:
>>> I have a prototype implementation of message modification times on my
>>> lastmod-v1 branch at
>>>
>>> https://github.com/acleme
On Mon, Sep 22 2014, Gaute Hope wrote:
> Excerpts from Gaute Hope's message of August 6, 2014 10:29:
>> Austin Clements wrote on Fri, 01 Aug 2014 14:55:05 -0400:
>>> I have a prototype implementation of message modification times on my
>>> lastmod-v1 branch at
>>>
>>> https://github.com/aclem
Excerpts from Gaute Hope's message of August 6, 2014 10:29:
Austin Clements wrote on Fri, 01 Aug 2014 14:55:05 -0400:
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 feat
Quoth Gaute Hope on Aug 06 at 11:02 am:
> On Fri, Aug 1, 2014 at 8:55 PM, Austin Clements wrote:
> > 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 featur
On Fri, Aug 1, 2014 at 8:55 PM, Austin Clements wrote:
> 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].
>
>
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
>
>
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
tim
On Thu, Jul 3, 2014 at 12:42 PM, David Bremner wrote:
> Gaute Hope 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
Gaute Hope 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 up
On Sat, 12 Apr 2014, David Bremner wrote:
> dm-list-email-notm...@scs.stanford.edu writes:
>
>>
>> As far as updating the test suite, etc., it's almost certain that the
>> core notmuch developers would be unsatisfied with whatever I've done,
>> since the code base is very clean and has a very unif
Austin Clements writes:
> I'd like to have efficient change detection, too. In my case, I'd
> like to use it to support efficient live search and show updates. The
> design I'd sketched out for that used a log rather than ctimes, and
> I'm curious if you have thoughts on the relative merits and
Austin Clements writes:
>> A middle ground might be to use the maximum of two values: 1) the
>> time-of-day at which notmuch started executing, and 2) the highest ctime
>> in the database plus 100 microseconds (leaving plenty of slop to store
>> timestamps as IEEE doubles with 52 significant bits
Quoth David Mazieres on Apr 06 at 10:19 pm:
> Gaute Hope 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
> > th
Hi Dave!
Quoth David Mazieres on Apr 23 at 2:00 am:
> Gaute Hope writes:
>
> > A db-tick or a _good_ ctime solution can as far as I can see solve both
> > David M's (correct me if I am wrong) and my purposes, as well as
> > probably have more use cases in the future. It would even be an
> > int
Excerpts from David Mazieres's message of 2014-04-23 11:00:10 +0200:
> Gaute Hope writes:
>
> > A db-tick or a _good_ ctime solution can as far as I can see solve both
> > David M's (correct me if I am wrong) and my purposes, as well as
> > probably have more use cases in the future. It would even
Gaute Hope writes:
> A db-tick or a _good_ ctime solution can as far as I can see solve both
> David M's (correct me if I am wrong) and my purposes, as well as
> probably have more use cases in the future. It would even be an
> interesting direct search: show me everything that changed lately,
>
Excerpts from David Bremner's message of 2014-04-23 00:05:02 +0200:
> Gaute Hope writes:
>
> >
> > I am talking about syncing tags to a maildir _folder_, not flags. It
> > could be implemented as maildir.synchronize is now, but it would be a
> > larger feature which could work in a lot of differen
Gaute Hope writes:
>
> I am talking about syncing tags to a maildir _folder_, not flags. It
> could be implemented as maildir.synchronize is now, but it would be a
> larger feature which could work in a lot of different ways.
>
So to try and clarify the use case, this could be used to add a tag
dm-list-email-notm...@scs.stanford.edu writes:
>
> As far as updating the test suite, etc., it's almost certain that the
> core notmuch developers would be unsatisfied with whatever I've done,
> since the code base is very clean and has a very uniform style. So when
> I say I'd want some "indicat
David Bremner writes:
>> Exactly. It could be a tick, or just the current time of day if your
>> clock does not go backwards. (I'd be willing to do a full scan if the
>> clock ever goes backwards.) The advantage of time is that you don't
>> have to synchronously update some counter.
>
> I thin
dm-list-email-notm...@scs.stanford.edu writes:
> Gaute Hope writes:
> Exactly. It could be a tick, or just the current time of day if your
> clock does not go backwards. (I'd be willing to do a full scan if the
> clock ever goes backwards.) The advantage of time is that you don't
> have to sy
Excerpts from dm-list-email-notmuch's message of 2014-04-10 17:31:04 +0200:
> Gaute Hope writes:
>
> >> A better approach would be to add a new "modtime" xapian value that is
> >> updated whenever the tags or any other terms (such as XFDIRENTRY) are
> >> added to or deleted from a docid. If it's
Gaute Hope writes:
>> A better approach would be to add a new "modtime" xapian value that is
>> updated whenever the tags or any other terms (such as XFDIRENTRY) are
>> added to or deleted from a docid. If it's a Xapian value, rather than a
>> term, then modtime will be queriable just like date,
Excerpts from David Mazieres's message of 2014-04-06 22:19:19 +0200:
> Gaute Hope 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
Gaute Hope 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 up
26 matches
Mail list logo
