Date: Thu, 18 Feb 2010 17:59:43 +1300
From: martin f krafft <madduck@madduck.net>
To: Ben Gamari <bgamari@gmail.com>
Message-ID: <20100218045943.GA6152@lapse.rw.madduck.net>
Mail-Followup-To: Ben Gamari <bgamari@gmail.com>,
	notmuch <notmuch@notmuchmail.org>
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>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: notmuch <notmuch@notmuchmail.org>
Subject: Re: [notmuch] nested tag trees (was:  Mail in git)
Precedence: list


--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

also sprach Ben Gamari <bgamari@gmail.com> [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--