1 Return-Path: <bgamari@gmail.com>
\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 A047E431FBC
\r
6 for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 17:01:25 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5
\r
12 tests=[AWL=-0.879, BAYES_50=0.001] autolearn=ham
\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 iRb4c94B65Y3 for <notmuch@notmuchmail.org>;
\r
16 Wed, 17 Feb 2010 17:01:24 -0800 (PST)
\r
17 Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com
\r
19 by olra.theworths.org (Postfix) with ESMTP id D5779431FAE
\r
20 for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 17:01:24 -0800 (PST)
\r
21 Received: by vws16 with SMTP id 16so675183vws.26
\r
22 for <notmuch@notmuchmail.org>; Wed, 17 Feb 2010 17:01:24 -0800 (PST)
\r
23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
\r
24 h=domainkey-signature:received:received:content-type:subject:from:to
\r
25 :in-reply-to:references:date:message-id:user-agent
\r
26 :content-transfer-encoding;
\r
27 bh=79qGzAW8CB8B3lAy8Uq1trXhZpbapnshxR7UGcfBja0=;
\r
28 b=ePs60i1tHOS3YGPKLlkExSG4jv8Hgt8zGN8ATspJOl3td05EOsHLGMhYjJk07ZIHJr
\r
29 rFtOBo3KEPjfQktvfS6d9kC8sBgd+hnRaXbE4f4Jg0mubYhFbLzY3SjpYV+zn5PZrTwX
\r
30 C+KHgC67s1Nt1oAC/tSyMXmCRqbWt/RWyE2pk=
\r
31 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
\r
32 h=content-type:subject:from:to:in-reply-to:references:date:message-id
\r
33 :user-agent:content-transfer-encoding;
\r
34 b=HL/1gZ2jTjyVI1BjcE2AzYcjvZBgX3ZXHsUWfEH88hsps3Hs7nPgvHaHFNob/jP+WK
\r
35 nfzxnlqRc6GPZ95H/c6UBhXYS9QToFJfgxgDO0t9iBJikqEGHhf4KqsocUFUdIhw997g
\r
36 M/QuBuivkqBG4DLU9NGRpZsolsKRiSuR6IIT8=
\r
37 Received: by 10.220.126.208 with SMTP id d16mr6376379vcs.20.1266454884464;
\r
38 Wed, 17 Feb 2010 17:01:24 -0800 (PST)
\r
39 Received: from localhost (umass-959-129.wireless.umass.edu [128.119.77.129])
\r
40 by mx.google.com with ESMTPS id 30sm22175501vws.1.2010.02.17.17.01.22
\r
41 (version=TLSv1/SSLv3 cipher=RC4-MD5);
\r
42 Wed, 17 Feb 2010 17:01:23 -0800 (PST)
\r
43 Content-Type: text/plain; charset=UTF-8
\r
44 From: Ben Gamari <bgamari@gmail.com>
\r
45 To: notmuch <notmuch@notmuchmail.org>
\r
46 In-reply-to: <87ljerju0q.fsf@willster.local.flamingspork.com>
\r
47 References: <20100215002914.GA22402@flamingspork.com>
\r
48 <20100217012101.GD8249@lapse.rw.madduck.net>
\r
49 <87ljerju0q.fsf@willster.local.flamingspork.com>
\r
50 Date: Wed, 17 Feb 2010 20:01:21 -0500
\r
51 Message-Id: <1266453575-sup-3653@ben-laptop>
\r
53 Content-Transfer-Encoding: 8bit
\r
54 Subject: Re: [notmuch] Mail in git
\r
55 X-BeenThere: notmuch@notmuchmail.org
\r
56 X-Mailman-Version: 2.1.13
\r
58 List-Id: "Use and development of the notmuch mail system."
\r
59 <notmuch.notmuchmail.org>
\r
60 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
61 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
62 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
63 List-Post: <mailto:notmuch@notmuchmail.org>
\r
64 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
65 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
66 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
67 X-List-Received-Date: Thu, 18 Feb 2010 01:01:25 -0000
\r
69 Excerpts from Stewart Smith's message of Wed Feb 17 18:56:53 -0500 2010:
\r
70 > On Wed, 17 Feb 2010 14:21:01 +1300, martin f krafft <madduck@madduck.net> wrote:
\r
71 > > What I am wondering is if (explicit) tags couldn't be represented as
\r
72 > > tree-objects with this.
\r
74 > I think it could get expensive for tags with lots of messages.
\r
76 > As far as I understand it, the tree object is stored in full and space
\r
77 > is only reclaimed during repack (due to delta compression).
\r
79 > So if you, say, had the entire history of a high volume list such as
\r
80 > linux-kernel, adding messages could get rather expensive if you
\r
81 > auto-tagged (or autotagged messages with patches or whatever).
\r
84 Well, it's tough to say, but I don't think it's as bad as you think. I
\r
85 proposed that we could use a tree structure like the following,
\r
100 ╰tagA.list4╶┼─msg11
\r
103 This way, adding a message to, say list3, would only require rewriting
\r
104 list3 and tagA, which seems pretty reasonable to me. Moreover, we could
\r
105 make the tree structure as deep as necessary, although we
\r
106 would need to rewrite a node at every level of the tree, so its tough
\r
107 saying how many levels is too many. It could simply be adaptive (e.g.
\r
108 bisect any nodes with more than N children).
\r
110 This certainly isn't as simple as the naive approach, but I think it's
\r
111 the only reasonable approach performance-wise and I don't believe it
\r
112 shouldn't be too tricky.
\r
114 > > messages would then be deleted whenever using git-gc.
\r
116 > > No idea how this would sync if we don't keep ancestry. Otoh, it
\r
117 > > would probably not be very expensive to do just that.
\r
119 > If we keep ancestry though, we are reusing existing working code for
\r
120 > backup (git-pull :)
\r
122 This is one of the reasons I feel it's important we keep it. And as is
\r
123 stated below, the storage overhead is minimal.
\r
125 > Keep in mind that with my tests, the Maildir in git is about a quarter
\r
126 > to a fifth of the size of it in Maildir... so a bit of extra usage per
\r
127 > message isn't as dramatic as it may sound.
\r
projects / notmuch-archives.git / blob