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--