From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 365FF431FBC for ; Wed, 17 Feb 2010 20:59:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWX9DKQNJX1P for ; Wed, 17 Feb 2010 20:59:50 -0800 (PST) Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96]) by olra.theworths.org (Postfix) with ESMTP id F18E6431FAE for ; Wed, 17 Feb 2010 20:59:49 -0800 (PST) Received: from lapse.rw.madduck.net (unknown [IPv6:2404:130:0:1000:20a:e4ff:fe30:4316]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lapse.rw.madduck.net", Issuer "CAcert Class 3 Root" (verified OK)) by clegg.madduck.net (postfix) with ESMTPS id 8AEAA1D409C; Thu, 18 Feb 2010 05:59:42 +0100 (CET) Received: by lapse.rw.madduck.net (Postfix, from userid 1000) id 2DF1024C; Thu, 18 Feb 2010 17:59:43 +1300 (NZDT) Date: Thu, 18 Feb 2010 17:59:43 +1300 From: martin f krafft To: Ben Gamari Message-ID: <20100218045943.GA6152@lapse.rw.madduck.net> Mail-Followup-To: Ben Gamari , notmuch References: <3wd3a0z7jjv.fsf@mhdcelk-nx01.amd.com> <1266435265-sup-5024@ben-laptop> <20100217235211.GC2628@lapse.rw.madduck.net> <1266453115-sup-7880@ben-laptop> <20100218015847.GB3480@lapse.rw.madduck.net> <1266459453-sup-7234@ben-laptop> <20100218024802.GA795@lapse.rw.madduck.net> <1266463007-sup-8777@ben-laptop> <20100218034613.GD1991@lapse.rw.madduck.net> <1266467977-sup-3504@ben-laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <1266467977-sup-3504@ben-laptop> X-Motto: Keep the good times rollin' X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.32-1-686 i686 X-Spamtrap: madduck.bogus@madduck.net X-Subliminal-Message: debian/rules! User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at clegg X-Virus-Status: Clean Cc: notmuch Subject: Re: nested tag trees (was: Mail in git) X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 04:59:51 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Ben Gamari [2010.02.18.1744 +1300]: > I believe you would. The problem isn't the messages (well, that's > a problem too), it's the fact that the tree (e.g. tab) objects > which reference the messages are immutable (I believe). This > presents us with the difficult circumstance of being unable to > modify a tag after it has been created. Therefore, as far as I can > tell, we need to rewrite the tag's tree object whenever we add or > remove a message. This was the reason I suggested nesting tag > trees, although this only partially solves the issue. You are absolutely right, and I think nesting tag trees is an interesting idea to pursue. It *would* make it impossible to ever check out the metatree into the filesystem, or rather result in subdirectories that the user shouldn't need to worry about. Instead of nested subtrees, think of 16 subtrees forming a level-1 hash table, or 256 for level-2, which really *ought* to be enough. Anyway, rewriting a tree object is pretty much exactly the same as removing a line (e.g. a message ID) from a file (e.g. a tag), as that file would have to be fully rewritten. > > This can probably be further optimised, but still: it's not > > quite as nice as enumerating all parents of a message in O(1) > > time (which would still result in O(m=D7n)). > >=20 > Yeah, I'm not sure how well this would scale on truly massive mail > stores. The more I think about this, the more I want to implement this between evenless and Git, i.e. as a porcelain layer, since then I could also use it for vcs-home[0]. In fact, maybe one day we can store ~ and mail all in one Git repo, with different porcelains for different use-cases, and notmuch indexing it all anyway. ;) 0. http://vcs-home.madduck.net Let's continue the technical discussion on the Git list, okay? http://marc.info/?l=3Dgit&m=3D126646636824600&w=3D2 id:20100218041240.GA4127@lapse.rw.madduck.net --=20 martin | http://madduck.net/ | http://two.sentenc.es/ =20 "i hate vulgar realism in literature. the man who could call a spade a spade should be compelled to use one. it is the only thing he is fit for." -- oscar wilde =20 spamtraps: madduck.bogus@madduck.net --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature; name="digital_signature_gpg.asc" Content-Description: Digital signature (see http://martin-krafft.net/gpg/) Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkt8yToACgkQIgvIgzMMSnU9fACgn34D5GpBavxgVn6ifGEccxcZ oPoAn1MaiaY1yjCiJZLVoWxQdFpzKI5l =/3ou -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--