fb/f79579a19ffe22df9ca0d46ab53baa0e53ddb9

   1 Return-Path: <tom.prince@ualberta.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 76748431FD0\r
   6         for <notmuch@notmuchmail.org>; Tue, 20 Dec 2011 07:23:44 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.804\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.804 tagged_above=-999 required=5\r
  12         tests=[DATE_IN_PAST_12_24=0.804] 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 FcEohHsB6WFR for <notmuch@notmuchmail.org>;\r
  16         Tue, 20 Dec 2011 07:23:43 -0800 (PST)\r
  17 Received: from socrates.hocat.ca (socrates.hocat.ca [76.10.188.53])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 3F5B6429E25\r
  19         for <notmuch@notmuchmail.org>; Tue, 20 Dec 2011 07:23:43 -0800 (PST)\r
  20 Received: from me (ares.hocat.ca [76.10.189.33])\r
  21         by socrates.hocat.ca (Postfix) with SMTP id 046571568;\r
  22         Tue, 20 Dec 2011 08:23:42 -0700 (MST)\r
  23 Received: (nullmailer pid 7197 invoked by uid 1000);\r
  24         Mon, 19 Dec 2011 22:56:39 -0000\r
  25 From: Tom Prince <tom.prince@ualberta.net>\r
  26 To: Austin Clements <amdragon@MIT.EDU>, David Edmondson <dme@dme.org>\r
  27 Subject: Re: [PATCH 0/5] Store message modification times in the DB\r
  28 In-Reply-To: <20111219194821.GA10376@mit.edu>\r
  29 References: <1323796305-28789-1-git-send-email-schnouki@schnouki.net>\r
  30         <cunk45szfiu.fsf@hotblack-desiato.hh.sledj.net>\r
  31         <20111219194821.GA10376@mit.edu>\r
  32 User-Agent: Notmuch/0.5-118-gdcdb843 (http://notmuchmail.org) Emacs/23.3.1\r
  33         (i686-pc-linux-gnu)\r
  34 Date: Mon, 19 Dec 2011 15:56:39 -0700\r
  35 Message-ID: <87r500cgrc.fsf@loki.hocat.ca>\r
  36 MIME-Version: 1.0\r
  37 Content-Type: text/plain; charset=us-ascii\r
  38 Cc: notmuch@notmuchmail.org\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.13\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43         <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Tue, 20 Dec 2011 15:23:44 -0000\r
  52 \r
  53 On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
  54 > This protocol requires significantly more state, but can also\r
  55 > reconstruct per-tag changes.  Conflict resolution is equivalent to\r
  56 > what git would do and is based solely on the current local and remote\r
  57 > state and the common ancestor state.\r
  58 \r
  59 This seems like exactly what one would get if one stored the tag state\r
  60 in git, which seems like a reasonable thing to do anyway. \r
  61 \r
  62 > This can lead to unintuitive results if a tag on a message has gone\r
  63 > through multiple changes on both hosts since the last sync (though, I\r
  64 > argue, there are no intuitive results in such situations).\r
  65 \r
  66 I certainly agree that there isn't a universally good resolution to\r
  67 this. I suspect that the same person, making the same tag changes with\r
  68 the same mtimes, will want different resolutions at different\r
  69 times. This is because there is no good way to record the intent of the\r
  70 changes.\r
  71 \r
  72 > Tombstones are only required to garbage collect sync state (and other\r
  73 > techniques could be used for that).\r
  74 \r
  75 I wonder how many people using notmuch actually delete mail? I know I\r
  76 don't bother to, anymore.\r
  77 \r
  78 One use case that was mentioned, is having a limited amount of mail on a\r
  79 portable device, and syncing tags on those message present. Using git to\r
  80 record the tag state, one would just need to record the state before\r
  81 deleting files, to avoid the need for tombstones in the notmuch db.\r
  82 \r
  83   Tom\r