From: Tilmann Singer <tils@tils.net>
To: David Mazieres expires 2014-07-12 PDT
	<mazieres-mbfu29xw9bpzdfpkk2m9i6pui2@temporary-address.scs.stanford.edu>,
	Brian Sniffen <bsniffen@akamai.com>, notmuch@notmuchmail.org
Subject: Re: Synchronization success stories?
In-Reply-To: <87siphl0cl.fsf@ta.scs.stanford.edu>
References: <m2r455f270.fsf@usma1mc-0csx92.kendall.corp.akamai.com>
	<87ppklwin6.fsf@tils.net> <87siphl0cl.fsf@ta.scs.stanford.edu>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-unknown-linux-gnu)
Date: Sun, 13 Apr 2014 21:08:49 +0200
Message-ID: <8738hhvygu.fsf@tils.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

David Mazieres <dm-list-email-notmuch@scs.stanford.edu> writes:
> What happens if you get a message that's been stuck in a queue for a few
> days and has an old Date: header?

It would be missed.  I have set the timespan to look backwards for new
mail to one month to be a bit safer against the stuck-in-queue cases,
but mails with older Date: headers would definitely get missed.

The current output of notmuch count "*" is the same on both the client
and the server, so it seems I didn't run into this problem yet (maybe I
was just lucky).

> Or if you get new messages that have
> the same Message-ID as old ones?

Is that even possible?  I thought that notmuch guarantees the uniqueness
of indexed message ids.  The only reference I could find without trying
to read the code was this thread id:87mwyz3s9d.fsf@star.eba from 2012,
which supports the assumption.

>> Synchronization of the notmuch tags database is only necessary when I
>> switch between different client computers, which happens less
>> frequently.
>
> Do you use a laptop everywhere?  I've found that for switching between
> my desktop machine at home, my laptop on the train, and my desktop at
> work (which amounts to five switches a day), the notmuch dump time is
> painfully slow--like well over 10 seconds for 100,000 messages.  Hook
> that into notmuch-poll and you have a recipe for hanging emacs every
> time you type "G".

I have one laptop and one desktop and switch between them almost daily,
and run a hibernate script that does notmuch dump + git push, and a
resume script that does git pull + notmuch restore.  For hibernate /
resume the speed of those operations is acceptable, but I wouldn't want
to incur that wait for every time checking for new mail.

Here is how long they take (on a machine with an SSD, which certainly
helps):

$ time notmuch dump --format=3Dbatch-tag | sort > /tmp/notmuch.dump
real    0m3.643s
user    0m3.593s
sys     0m0.140s
$ time notmuch restore < /tmp/notmuch.dump
real    0m3.719s
user    0m3.357s
sys     0m0.357s
$ notmuch count=20
117118



Til

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJTSuDBAAoJEIPWI/RHW7lzuHkH/1ToBjsD6Wri2mwf8LxJ2hqR
p4Lyq2U9w/ZP7YyBKjFwyhOAVJ8Cj9bbLw84kbUIJoxLRTzwJHPB4aEv67ktD+3y
4UCQUf5579BdnjASBblHDP3NySsJkSybkn1N2WCCGhoiAyvK+0J5CizebcAYVELv
FY8lG4c9aWaMi2KNiOeBxjKu8NrwKMVI1munBDIGhNxiAAqYqqyfszJQQcvrOkAK
g40CwuugOvXt20iMloBFsBxz+fv3jvHMdpyVT4+w7Rb3PoREkFt5tf5FL0xMmPIV
hrIlfVrqTCdL9lMql3ppOcNEbsQIZzq6oAhWIBLGW8RaPO6eUoMvDFJsPwOycfg=
=imbw
-----END PGP SIGNATURE-----
--=-=-=--