Re: Synchronization success stories?

diff --git a/27/8b2df1dec1504ee32b5a389bd9ab9398ef170b b/27/8b2df1dec1504ee32b5a389bd9ab9398ef170b
new file mode 100644 (file)
index 0000000..8b2c0db
--- /dev/null
+++ b/27/8b2df1dec1504ee32b5a389bd9ab9398ef170b
@@ -0,0 +1,127 @@
+Return-Path: <tils@tils.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 23004431FBD\r
+       for <notmuch@notmuchmail.org>; Sun, 13 Apr 2014 12:09:01 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id HGdk+e9BtznK for <notmuch@notmuchmail.org>;\r
+       Sun, 13 Apr 2014 12:08:53 -0700 (PDT)\r
+Received: from goto.r-w-x.org (goto.r-w-x.org [176.9.70.178])\r
+       by olra.theworths.org (Postfix) with ESMTP id 74E22431FBC\r
+       for <notmuch@notmuchmail.org>; Sun, 13 Apr 2014 12:08:53 -0700 (PDT)\r
+Received: from localhost (55d456ec.access.ecotel.net [85.212.86.236])\r
+       by goto.r-w-x.org (Postfix) with ESMTPSA id 195C9E5C;\r
+       Sun, 13 Apr 2014 21:08:50 +0200 (CEST)\r
+Received: by localhost (sSMTP sendmail emulation);\r
+       Sun, 13 Apr 2014 21:08:49 +0200\r
+From: Tilmann Singer <tils@tils.net>\r
+To: David Mazieres expires 2014-07-12 PDT\r
+       <mazieres-mbfu29xw9bpzdfpkk2m9i6pui2@temporary-address.scs.stanford.edu>,\r
+       Brian Sniffen <bsniffen@akamai.com>, notmuch@notmuchmail.org\r
+Subject: Re: Synchronization success stories?\r
+In-Reply-To: <87siphl0cl.fsf@ta.scs.stanford.edu>\r
+References: <m2r455f270.fsf@usma1mc-0csx92.kendall.corp.akamai.com>\r
+       <87ppklwin6.fsf@tils.net> <87siphl0cl.fsf@ta.scs.stanford.edu>\r
+User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-unknown-linux-gnu)\r
+Date: Sun, 13 Apr 2014 21:08:49 +0200\r
+Message-ID: <8738hhvygu.fsf@tils.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 13 Apr 2014 19:09:01 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+David Mazieres <dm-list-email-notmuch@scs.stanford.edu> writes:\r
+> What happens if you get a message that's been stuck in a queue for a few\r
+> days and has an old Date: header?\r
+\r
+It would be missed.  I have set the timespan to look backwards for new\r
+mail to one month to be a bit safer against the stuck-in-queue cases,\r
+but mails with older Date: headers would definitely get missed.\r
+\r
+The current output of notmuch count "*" is the same on both the client\r
+and the server, so it seems I didn't run into this problem yet (maybe I\r
+was just lucky).\r
+\r
+> Or if you get new messages that have\r
+> the same Message-ID as old ones?\r
+\r
+Is that even possible?  I thought that notmuch guarantees the uniqueness\r
+of indexed message ids.  The only reference I could find without trying\r
+to read the code was this thread id:87mwyz3s9d.fsf@star.eba from 2012,\r
+which supports the assumption.\r
+\r
+>> Synchronization of the notmuch tags database is only necessary when I\r
+>> switch between different client computers, which happens less\r
+>> frequently.\r
+>\r
+> Do you use a laptop everywhere?  I've found that for switching between\r
+> my desktop machine at home, my laptop on the train, and my desktop at\r
+> work (which amounts to five switches a day), the notmuch dump time is\r
+> painfully slow--like well over 10 seconds for 100,000 messages.  Hook\r
+> that into notmuch-poll and you have a recipe for hanging emacs every\r
+> time you type "G".\r
+\r
+I have one laptop and one desktop and switch between them almost daily,\r
+and run a hibernate script that does notmuch dump + git push, and a\r
+resume script that does git pull + notmuch restore.  For hibernate /\r
+resume the speed of those operations is acceptable, but I wouldn't want\r
+to incur that wait for every time checking for new mail.\r
+\r
+Here is how long they take (on a machine with an SSD, which certainly\r
+helps):\r
+\r
+$ time notmuch dump --format=3Dbatch-tag | sort > /tmp/notmuch.dump\r
+real    0m3.643s\r
+user    0m3.593s\r
+sys     0m0.140s\r
+$ time notmuch restore < /tmp/notmuch.dump\r
+real    0m3.719s\r
+user    0m3.357s\r
+sys     0m0.357s\r
+$ notmuch count=20\r
+117118\r
+\r
+\r
+\r
+Til\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v2.0.22 (GNU/Linux)\r
+\r
+iQEcBAEBAgAGBQJTSuDBAAoJEIPWI/RHW7lzuHkH/1ToBjsD6Wri2mwf8LxJ2hqR\r
+p4Lyq2U9w/ZP7YyBKjFwyhOAVJ8Cj9bbLw84kbUIJoxLRTzwJHPB4aEv67ktD+3y\r
+4UCQUf5579BdnjASBblHDP3NySsJkSybkn1N2WCCGhoiAyvK+0J5CizebcAYVELv\r
+FY8lG4c9aWaMi2KNiOeBxjKu8NrwKMVI1munBDIGhNxiAAqYqqyfszJQQcvrOkAK\r
+g40CwuugOvXt20iMloBFsBxz+fv3jvHMdpyVT4+w7Rb3PoREkFt5tf5FL0xMmPIV\r
+hrIlfVrqTCdL9lMql3ppOcNEbsQIZzq6oAhWIBLGW8RaPO6eUoMvDFJsPwOycfg=\r
+=imbw\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r