27/8b2df1dec1504ee32b5a389bd9ab9398ef170b

   1 Return-Path: <tils@tils.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 23004431FBD\r
   6         for <notmuch@notmuchmail.org>; Sun, 13 Apr 2014 12:09:01 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id HGdk+e9BtznK for <notmuch@notmuchmail.org>;\r
  16         Sun, 13 Apr 2014 12:08:53 -0700 (PDT)\r
  17 Received: from goto.r-w-x.org (goto.r-w-x.org [176.9.70.178])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 74E22431FBC\r
  19         for <notmuch@notmuchmail.org>; Sun, 13 Apr 2014 12:08:53 -0700 (PDT)\r
  20 Received: from localhost (55d456ec.access.ecotel.net [85.212.86.236])\r
  21         by goto.r-w-x.org (Postfix) with ESMTPSA id 195C9E5C;\r
  22         Sun, 13 Apr 2014 21:08:50 +0200 (CEST)\r
  23 Received: by localhost (sSMTP sendmail emulation);\r
  24         Sun, 13 Apr 2014 21:08:49 +0200\r
  25 From: Tilmann Singer <tils@tils.net>\r
  26 To: David Mazieres expires 2014-07-12 PDT\r
  27         <mazieres-mbfu29xw9bpzdfpkk2m9i6pui2@temporary-address.scs.stanford.edu>,\r
  28         Brian Sniffen <bsniffen@akamai.com>, notmuch@notmuchmail.org\r
  29 Subject: Re: Synchronization success stories?\r
  30 In-Reply-To: <87siphl0cl.fsf@ta.scs.stanford.edu>\r
  31 References: <m2r455f270.fsf@usma1mc-0csx92.kendall.corp.akamai.com>\r
  32         <87ppklwin6.fsf@tils.net> <87siphl0cl.fsf@ta.scs.stanford.edu>\r
  33 User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1\r
  34         (x86_64-unknown-linux-gnu)\r
  35 Date: Sun, 13 Apr 2014 21:08:49 +0200\r
  36 Message-ID: <8738hhvygu.fsf@tils.net>\r
  37 MIME-Version: 1.0\r
  38 Content-Type: multipart/signed; boundary="=-=-=";\r
  39         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.13\r
  42 Precedence: list\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44         <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Sun, 13 Apr 2014 19:09:01 -0000\r
  53 \r
  54 --=-=-=\r
  55 Content-Type: text/plain\r
  56 Content-Transfer-Encoding: quoted-printable\r
  57 \r
  58 David Mazieres <dm-list-email-notmuch@scs.stanford.edu> writes:\r
  59 > What happens if you get a message that's been stuck in a queue for a few\r
  60 > days and has an old Date: header?\r
  61 \r
  62 It would be missed.  I have set the timespan to look backwards for new\r
  63 mail to one month to be a bit safer against the stuck-in-queue cases,\r
  64 but mails with older Date: headers would definitely get missed.\r
  65 \r
  66 The current output of notmuch count "*" is the same on both the client\r
  67 and the server, so it seems I didn't run into this problem yet (maybe I\r
  68 was just lucky).\r
  69 \r
  70 > Or if you get new messages that have\r
  71 > the same Message-ID as old ones?\r
  72 \r
  73 Is that even possible?  I thought that notmuch guarantees the uniqueness\r
  74 of indexed message ids.  The only reference I could find without trying\r
  75 to read the code was this thread id:87mwyz3s9d.fsf@star.eba from 2012,\r
  76 which supports the assumption.\r
  77 \r
  78 >> Synchronization of the notmuch tags database is only necessary when I\r
  79 >> switch between different client computers, which happens less\r
  80 >> frequently.\r
  81 >\r
  82 > Do you use a laptop everywhere?  I've found that for switching between\r
  83 > my desktop machine at home, my laptop on the train, and my desktop at\r
  84 > work (which amounts to five switches a day), the notmuch dump time is\r
  85 > painfully slow--like well over 10 seconds for 100,000 messages.  Hook\r
  86 > that into notmuch-poll and you have a recipe for hanging emacs every\r
  87 > time you type "G".\r
  88 \r
  89 I have one laptop and one desktop and switch between them almost daily,\r
  90 and run a hibernate script that does notmuch dump + git push, and a\r
  91 resume script that does git pull + notmuch restore.  For hibernate /\r
  92 resume the speed of those operations is acceptable, but I wouldn't want\r
  93 to incur that wait for every time checking for new mail.\r
  94 \r
  95 Here is how long they take (on a machine with an SSD, which certainly\r
  96 helps):\r
  97 \r
  98 $ time notmuch dump --format=3Dbatch-tag | sort > /tmp/notmuch.dump\r
  99 real    0m3.643s\r
 100 user    0m3.593s\r
 101 sys     0m0.140s\r
 102 $ time notmuch restore < /tmp/notmuch.dump\r
 103 real    0m3.719s\r
 104 user    0m3.357s\r
 105 sys     0m0.357s\r
 106 $ notmuch count=20\r
 107 117118\r
 108 \r
 109 \r
 110 \r
 111 Til\r
 112 \r
 113 --=-=-=\r
 114 Content-Type: application/pgp-signature\r
 115 \r
 116 -----BEGIN PGP SIGNATURE-----\r
 117 Version: GnuPG v2.0.22 (GNU/Linux)\r
 118 \r
 119 iQEcBAEBAgAGBQJTSuDBAAoJEIPWI/RHW7lzuHkH/1ToBjsD6Wri2mwf8LxJ2hqR\r
 120 p4Lyq2U9w/ZP7YyBKjFwyhOAVJ8Cj9bbLw84kbUIJoxLRTzwJHPB4aEv67ktD+3y\r
 121 4UCQUf5579BdnjASBblHDP3NySsJkSybkn1N2WCCGhoiAyvK+0J5CizebcAYVELv\r
 122 FY8lG4c9aWaMi2KNiOeBxjKu8NrwKMVI1munBDIGhNxiAAqYqqyfszJQQcvrOkAK\r
 123 g40CwuugOvXt20iMloBFsBxz+fv3jvHMdpyVT4+w7Rb3PoREkFt5tf5FL0xMmPIV\r
 124 hrIlfVrqTCdL9lMql3ppOcNEbsQIZzq6oAhWIBLGW8RaPO6eUoMvDFJsPwOycfg=\r
 125 =imbw\r
 126 -----END PGP SIGNATURE-----\r
 127 --=-=-=--\r