From: David Bremner <david@tethera.net>
To: David Mazieres expires 2014-07-09 PDT
	<mazieres-gzp7rfravpipmg73ew8cs6n6t6@temporary-address.scs.stanford.edu>,
	Gaute Hope <eg@gaute.vetsj.com>
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 <notmuch@notmuchmail.org>
Precedence: list

dm-list-email-notmuch@scs.stanford.edu writes:

> Gaute Hope <eg@gaute.vetsj.com> 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.