From: David Bremner Date: Fri, 11 Apr 2014 11:08:46 +0000 (+2100) Subject: Re: [PATCH] Add configurable changed tag to messages that have been changed on disk X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=67275eeab6772fc252bdb4bb28cd2345cc155c66;p=notmuch-archives.git Re: [PATCH] Add configurable changed tag to messages that have been changed on disk --- diff --git a/47/51277ef23b7cd84fc326a304a7f018b9f5e6b8 b/47/51277ef23b7cd84fc326a304a7f018b9f5e6b8 new file mode 100644 index 000000000..6aa317acd --- /dev/null +++ b/47/51277ef23b7cd84fc326a304a7f018b9f5e6b8 @@ -0,0 +1,91 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 1DE9A431FAF + for ; Fri, 11 Apr 2014 04:09:04 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id ZjtPbJ1G8cVB for ; + Fri, 11 Apr 2014 04:08:58 -0700 (PDT) +Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155]) + (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 2CFA4431FAE + for ; Fri, 11 Apr 2014 04:08:58 -0700 (PDT) +Received: from remotemail by yantan.tethera.net with local (Exim 4.80) + (envelope-from ) + id 1WYZKE-0004WO-4E; Fri, 11 Apr 2014 08:08:50 -0300 +Received: (nullmailer pid 6460 invoked by uid 1000); Fri, 11 Apr 2014 + 11:08:46 -0000 +From: David Bremner +To: David Mazieres expires 2014-07-09 PDT + , + Gaute Hope +Subject: Re: [PATCH] Add configurable changed tag to messages that have been + changed on disk +In-Reply-To: <87wqexnqvb.fsf@ta.scs.stanford.edu> +References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com> + <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila> + <87wqexnqvb.fsf@ta.scs.stanford.edu> +User-Agent: Notmuch/0.17+180~g8977b1a (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-pc-linux-gnu) +Date: Fri, 11 Apr 2014 08:08:46 -0300 +Message-ID: <87k3aw5dj5.fsf@zancas.localnet> +MIME-Version: 1.0 +Content-Type: text/plain +Cc: notmuch +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +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: Fri, 11 Apr 2014 11:09:04 -0000 + +dm-list-email-notmuch@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 synchronously update some counter. + +I think I'd lean towards global time so that one could use it to resolve +conflicts between changes to multiple copies of the database. + +> Making sure the write-operations update the time should be easy. Most +> or all of the changes are probably funneled through +> _notmuch_message_sync. Worst case, there are only 9 places in the +> source code that make use of a Xapian:WritableDatabase, so I'm pretty +> confident total changes wouldn't be much more than 50 lines of code. + +Maybe. Don't forget upgrading the database, updating the test suite, and +presumably some changes to the CLI so the new mtime can actually be +used. Not to be discouraging ;). + +> I would do it myself if there were any kind of indication that such a +> change could be upstreamed. I brought this up in January, 2011, and +> didn't get a huge amount of interest in the ctime idea. But I was also +> a lot less focused on what I needed. Now that I have a working +> distributed setup and am actually using notmuch for my mail, I have a +> much better understanding of what is needed. + +In the ensuing time, nothing better has developed for tag +synchronization (my pet use case) so maybe it's time to pursue this +again. It would be good to have some preliminary idea about the time +and space costs of adding document mtimes. I guess database bloat +should not be too bad, since it's only 64bits (?) per mail message.