Austin Clements writes:
> Sure. I've been wanting to take a crack at notmuch new's atomicity for
> a while. Though you'll have to get through some of my outstanding
> patches. I can only keep so many branches in my head. ]:--8)
>
> rlb, you expressed an interest in solving this problem, too. Did
Austin Clements writes:
> Sure. I've been wanting to take a crack at notmuch new's atomicity for
> a while. Though you'll have to get through some of my outstanding
> patches. I can only keep so many branches in my head. ]:--8)
>
> rlb, you expressed an interest in solving this problem, too. Did
On Thu, 27 Jan 2011 19:08:38 -0500, Austin Clements wrote:
> I added a "notmuch_database_remove_message_get" to the public API that's
> just like "notmuch_database_remove_message" except that it also returns a
> notmuch_message_t if other instances of the message still exist. It feels
> clunky t
On Thu, 27 Jan 2011 19:08:38 -0500, Austin Clements wrote:
> I added a "notmuch_database_remove_message_get" to the public API that's
> just like "notmuch_database_remove_message" except that it also returns a
> notmuch_message_t if other instances of the message still exist. It feels
> clunky t
Looks like eagerly synchronizing tags is easy and works fine, though I need
to beef up the tests and put some transactions around things before I'm
satisfied.
I added a "notmuch_database_remove_message_get" to the public API that's
just like "notmuch_database_remove_message" except that it also re
Looks like eagerly synchronizing tags is easy and works fine, though I need
to beef up the tests and put some transactions around things before I'm
satisfied.
I added a "notmuch_database_remove_message_get" to the public API that's
just like "notmuch_database_remove_message" except that it also re
On Wed, 26 Jan 2011 10:07:28 -0500, Austin Clements wrote:
> Quoth Carl Worth on Jan 26 at 9:59 pm:
>
> I believe you're right that synchronization could always be done
> eagerly. In fact, I believe this is true even with the addition of
> conjunctive and disjunctive flags.
Excellent! Want to
Sure. I've been wanting to take a crack at notmuch new's atomicity for a while.
Though you'll have to get through some of my outstanding patches. I can only
keep so many branches in my head. ]:--8)
rlb, you expressed an interest in solving this problem, too. Did you make any
headway?
"Carl Wor
On Wed, 26 Jan 2011 19:15:21 +1000, Carl Worth wrote:
> Yes, that is much simpler and should work equally well as the original
> patch.
...
> So, I think I've convinced myself that the change is actually OK.
For those reasons, I'm pushing the patch now.
> But then I'm also wondering if perhaps w
Sure. I've been wanting to take a crack at notmuch new's atomicity for a while.
Though you'll have to get through some of my outstanding patches. I can only
keep so many branches in my head. ]:--8)
rlb, you expressed an interest in solving this problem, too. Did you make any
headway?
"Carl Wor
On Wed, 26 Jan 2011 10:07:28 -0500, Austin Clements wrote:
> Quoth Carl Worth on Jan 26 at 9:59 pm:
>
> I believe you're right that synchronization could always be done
> eagerly. In fact, I believe this is true even with the addition of
> conjunctive and disjunctive flags.
Excellent! Want to
On Tue, 25 Jan 2011 17:42:30 -0500, Austin Clements wrote:
> Wouldn't this be simpler and more general?
...
> case NOTMUCH_STATUS_SUCCESS:
..
> if (state->synchronize_flags == TRUE)
> - _filename_list_add (state->message_ids_to_sync,
> -
On Wed, 26 Jan 2011, Austin Clements wrote:
> The one other change is that currently, if notmuch is interrupted
> after updating a directory mtime but before processing file removals,
> a subsequent notmuch new will miss those removals. This could be
> brushed under the rug, since notmuch will not
Quoth Carl Worth on Jan 26 at 9:59 pm:
> On Wed, 26 Jan 2011 19:15:21 +1000, Carl Worth wrote:
> > But then I'm also wondering if perhaps we could do the processing undeferred
> > in all cases?
> >
> > I haven't thought that through, but I'd be glad to hear your ideas.
>
> This is still an open
On Wed, 26 Jan 2011, Austin Clements wrote:
> The one other change is that currently, if notmuch is interrupted
> after updating a directory mtime but before processing file removals,
> a subsequent notmuch new will miss those removals. This could be
> brushed under the rug, since notmuch will not
Quoth Carl Worth on Jan 26 at 9:59 pm:
> On Wed, 26 Jan 2011 19:15:21 +1000, Carl Worth wrote:
> > But then I'm also wondering if perhaps we could do the processing undeferred
> > in all cases?
> >
> > I haven't thought that through, but I'd be glad to hear your ideas.
>
> This is still an open
On Wed, 26 Jan 2011 19:15:21 +1000, Carl Worth wrote:
> Yes, that is much simpler and should work equally well as the original
> patch.
...
> So, I think I've convinced myself that the change is actually OK.
For those reasons, I'm pushing the patch now.
> But then I'm also wondering if perhaps w
On Tue, 25 Jan 2011 17:42:30 -0500, Austin Clements wrote:
> Wouldn't this be simpler and more general?
...
> case NOTMUCH_STATUS_SUCCESS:
..
> if (state->synchronize_flags == TRUE)
> - _filename_list_add (state->message_ids_to_sync,
> -
Wouldn't this be simpler and more general?
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -419,12 +419,11 @@ add_files_recursive (notmuch_database_t *notmuch,
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
for (tag=state->new_tags; *tag != NULL; tag++)
Wouldn't this be simpler and more general?
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -419,12 +419,11 @@ add_files_recursive (notmuch_database_t *notmuch,
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
for (tag=state->new_tags; *tag != NULL; tag++)
When notmuch new is run for the first time, it is not necessary to defer
maildir flags synchronization to later because we already know that no
files will be removed.
Performing the maildinr flag synchronization immediately after the
message is added to the database has the advantage that the mess
When notmuch new is run for the first time, it is not necessary to defer
maildir flags synchronization to later because we already know that no
files will be removed.
Performing the maildinr flag synchronization immediately after the
message is added to the database has the advantage that the mess
22 matches
Mail list logo
