1 Return-Path: <sojkam1@fel.cvut.cz>
\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 81CAC431FBC
\r
6 for <notmuch@notmuchmail.org>; Fri, 19 Feb 2010 01:52:25 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5
\r
12 tests=[AWL=-0.411, BAYES_05=-1.11] 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 HQY3qErMf3+1 for <notmuch@notmuchmail.org>;
\r
16 Fri, 19 Feb 2010 01:52:24 -0800 (PST)
\r
17 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])
\r
18 by olra.theworths.org (Postfix) with ESMTP id 840E0431FAE
\r
19 for <notmuch@notmuchmail.org>; Fri, 19 Feb 2010 01:52:24 -0800 (PST)
\r
20 Received: from localhost (unknown [192.168.200.4])
\r
21 by max.feld.cvut.cz (Postfix) with ESMTP id A766319F33BC;
\r
22 Fri, 19 Feb 2010 10:52:23 +0100 (CET)
\r
23 X-Virus-Scanned: IMAP AMAVIS
\r
24 Received: from max.feld.cvut.cz ([192.168.200.1])
\r
25 by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,
\r
27 with ESMTP id dMwR9V13LHXu; Fri, 19 Feb 2010 10:52:19 +0100 (CET)
\r
28 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])
\r
29 by max.feld.cvut.cz (Postfix) with ESMTP id 83A2119F334D;
\r
30 Fri, 19 Feb 2010 10:52:19 +0100 (CET)
\r
31 Received: from steelpick.localdomain (k335-30.felk.cvut.cz [147.32.86.30])
\r
32 (Authenticated sender: sojkam1)
\r
33 by imap.feld.cvut.cz (Postfix) with ESMTPSA id 51C4DFA004;
\r
34 Fri, 19 Feb 2010 10:52:19 +0100 (CET)
\r
35 Received: from wsh by steelpick.localdomain with local (Exim 4.71)
\r
36 (envelope-from <sojkam1@fel.cvut.cz>)
\r
37 id 1NiPX1-0008Tr-4W; Fri, 19 Feb 2010 10:52:19 +0100
\r
38 From: Michal Sojka <sojkam1@fel.cvut.cz>
\r
39 To: martin f krafft <madduck@madduck.net>, Ben Gamari <bgamari@gmail.com>
\r
40 In-Reply-To: <20100219003115.GB25162@lapse.rw.madduck.net>
\r
41 References: <20100217235211.GC2628@lapse.rw.madduck.net>
\r
42 <1266453115-sup-7880@ben-laptop>
\r
43 <20100218015847.GB3480@lapse.rw.madduck.net>
\r
44 <1266459453-sup-7234@ben-laptop>
\r
45 <20100218024802.GA795@lapse.rw.madduck.net>
\r
46 <1266463007-sup-8777@ben-laptop>
\r
47 <20100218034613.GD1991@lapse.rw.madduck.net>
\r
48 <1266467977-sup-3504@ben-laptop>
\r
49 <20100218045943.GA6152@lapse.rw.madduck.net>
\r
50 <1266469478-sup-2095@ben-laptop>
\r
51 <20100219003115.GB25162@lapse.rw.madduck.net>
\r
52 Date: Fri, 19 Feb 2010 10:52:18 +0100
\r
53 Message-ID: <87r5ohimct.fsf@steelpick.localdomain>
\r
55 Content-Type: text/plain; charset=utf-8
\r
56 Content-Transfer-Encoding: quoted-printable
\r
57 Cc: notmuch <notmuch@notmuchmail.org>
\r
58 Subject: Re: [notmuch] nested tag trees (was: Mail in git)
\r
59 X-BeenThere: notmuch@notmuchmail.org
\r
60 X-Mailman-Version: 2.1.13
\r
62 List-Id: "Use and development of the notmuch mail system."
\r
63 <notmuch.notmuchmail.org>
\r
64 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
65 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
66 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
67 List-Post: <mailto:notmuch@notmuchmail.org>
\r
68 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
69 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
70 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
71 X-List-Received-Date: Fri, 19 Feb 2010 09:52:25 -0000
\r
73 On Fri, 19 Feb 2010 13:31:15 +1300, martin f krafft <madduck@madduck.net> w=
\r
75 > also sprach Ben Gamari <bgamari@gmail.com> [2010.02.18.1810 +1300]:
\r
76 > > > Instead of nested subtrees, think of 16 subtrees forming
\r
77 > > > a level-1 hash table, or 256 for level-2, which really *ought*
\r
80 > > > Anyway, rewriting a tree object is pretty much exactly the same
\r
81 > > > as removing a line (e.g. a message ID) from a file (e.g. a tag),
\r
82 > > > as that file would have to be fully rewritten.
\r
84 > > This is very true, but exactly do you mean by this statement?
\r
86 > That any form of tag-to-message mapping will be expensive when you
\r
87 > have a million messages referenced. If you used symlinks like mairix
\r
88 > does, any manipulation would require changes to the directory index,
\r
89 > which =E2=80=94 curiously =E2=80=94 functions much like the subtree appro=
\r
93 Why do you want to store tag-to-message mapping in git? This is IMHO
\r
94 perfectly solved by Xapian so storing message-to-tag mapping would be
\r
95 sufficient, wouldn't it?
\r