From: Austin Clements Date: Sat, 8 Aug 2015 13:05:31 +0000 (+2000) Subject: Re: [PATCH 2/6] lib: Add per-message last modification tracking X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=05e117e0ccad391b245a85c4b9d67c05541b49c4;p=notmuch-archives.git Re: [PATCH 2/6] lib: Add per-message last modification tracking --- diff --git a/55/2d798d0bfd607089eb228303bd409df4dec19f b/55/2d798d0bfd607089eb228303bd409df4dec19f new file mode 100644 index 000000000..7618c422e --- /dev/null +++ b/55/2d798d0bfd607089eb228303bd409df4dec19f @@ -0,0 +1,164 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id 7A4686DE0924 + for ; Sat, 8 Aug 2015 06:27:19 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: -2.126 +X-Spam-Level: +X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 + tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, + RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, + RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001, URIBL_SBL=0.644, + URIBL_SBL_A=0.1] autolearn=disabled +Received: from arlo.cworth.org ([127.0.0.1]) + by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id ugghzyetOPjk for ; + Sat, 8 Aug 2015 06:27:17 -0700 (PDT) +X-Greylist: delayed 1302 seconds by postgrey-1.35 at arlo; + Sat, 08 Aug 2015 06:27:17 PDT +Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) + by arlo.cworth.org (Postfix) with ESMTP id 2742C6DE02D2 + for ; Sat, 8 Aug 2015 06:27:17 -0700 (PDT) +Received: from mail-qk0-f174.google.com ([209.85.220.174]) + by outgoing.csail.mit.edu with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) + (Exim 4.72) (envelope-from ) + id 1ZO3oa-0001Kk-UC + for notmuch@notmuchmail.org; Sat, 08 Aug 2015 09:05:33 -0400 +Received: by qkdv3 with SMTP id v3so45472883qkd.3 + for ; Sat, 08 Aug 2015 06:05:32 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.55.26.93 with SMTP id a90mr23194257qka.63.1439039132115; + Sat, 08 Aug 2015 06:05:32 -0700 (PDT) +Received: by 10.96.197.42 with HTTP; Sat, 8 Aug 2015 06:05:31 -0700 (PDT) +Received: by 10.96.197.42 with HTTP; Sat, 8 Aug 2015 06:05:31 -0700 (PDT) +In-Reply-To: <87r3ne96li.fsf@maritornes.cs.unb.ca> +References: <1432936375-astroid-4-0i1n6yczs2-1520@strange> + <1433525318-23756-1-git-send-email-david@tethera.net> + <1433525318-23756-3-git-send-email-david@tethera.net> + <878u9nk0st.fsf@schoepe.localhost> + <87r3ne96li.fsf@maritornes.cs.unb.ca> +Date: Sat, 8 Aug 2015 09:05:31 -0400 +Message-ID: + +Subject: Re: [PATCH 2/6] lib: Add per-message last modification tracking +From: Austin Clements +To: David Bremner +Content-Type: multipart/alternative; boundary=001a1146cb2a49acdd051ccc688b +Cc: notmuch +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.18 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sat, 08 Aug 2015 13:27:19 -0000 + +--001a1146cb2a49acdd051ccc688b +Content-Type: text/plain; charset=UTF-8 + +Hi David. I haven't had a chance to look back at the original code, but +your follow-up expanded comment agrees with how I remember this code +working. +On Aug 7, 2015 4:41 PM, "David Bremner" wrote: + +> Daniel Schoepe writes: +> +> +> > On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote: +> >> + /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not +> >> + * track modification revisions. Give all messages a +> >> + * revision of 1. +> >> + */ +> >> + if (new_features & NOTMUCH_FEATURE_LAST_MOD) +> >> + _notmuch_message_upgrade_last_mod (message); +> >> [..] +> >> +/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD. The caller +> >> + * must call _notmuch_message_sync. */ +> >> +void +> >> +_notmuch_message_upgrade_last_mod (notmuch_message_t *message) +> >> +{ +> >> + /* _notmuch_message_sync will update the last modification +> >> + * revision; we just have to ask it to. */ +> >> + message->modified = TRUE; +> >> +} +> >> + +> > +> > The comment in the first part says that message without LAST_MOD get a +> > revision of 1, but as far as I can tell, _notmuch_message_sync will +> > actually put the next revision number on the message. If this is what's +> > happening, either the comment or the behavior should be changed, +> > depending on what's intended. +> +> I think the behaviour is OK, but you're correct the comment is +> wrong. I'll see if Austin has any comment on that. I guess it would be +> harmless to initialize upgraded messages to some low revision number, +> but I don't see the benefit. +> + +--001a1146cb2a49acdd051ccc688b +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +

Hi David. I haven't had a chance to look back at the ori= +ginal code, but your follow-up expanded comment agrees with how I remember = +this code working.

+
On Aug 7, 2015 4:41 PM, "David Bremner"= +; <david@tethera.net> wrote:= +
Daniel Schoepe <= +daniel@schoepe.org> writes: +
+
+> On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
+>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Prior to NOTMUCH_FEATURE_LAST_MOD,= + messages did not
+>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* track modification revisions.= +=C2=A0 Give all messages a
+>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* revision of 1.
+>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
+>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (new_features & NOTMUCH_FEATUR= +E_LAST_MOD)
+>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _notmuch_message_upgrad= +e_last_mod (message);
+>> [..]
+>> +/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD.=C2=A0 T= +he caller
+>> + * must call _notmuch_message_sync. */
+>> +void
+>> +_notmuch_message_upgrade_last_mod (notmuch_message_t *message) +>> +{
+>> +=C2=A0 =C2=A0 /* _notmuch_message_sync will update the last modif= +ication
+>> +=C2=A0 =C2=A0 =C2=A0* revision; we just have to ask it to. */
+>> +=C2=A0 =C2=A0 message->modified =3D TRUE;
+>> +}
+>> +
+>
+> The comment in the first part says that message without LAST_MOD get a= +
+> revision of 1, but as far as I can tell, _notmuch_message_sync will +> actually put the next revision number on the message. If this is what&= +#39;s
+> happening, either the comment or the behavior should be changed,
+> depending on what's intended.
+
+I think the behaviour is OK, but you're correct the comment is
+wrong. I'll see if Austin has any comment on that. I guess it would be<= +br> +harmless to initialize upgraded messages to some low revision number,
+but I don't see the benefit.
+
+ +--001a1146cb2a49acdd051ccc688b--