[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Path lookup table (was: Re: Locking design (was Re: svn commit: r9885 - trunk/notes))

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-05-29 03:55:35 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

> I think it's important to answer these questions before we look at a
> table of this nature as a future direction for FS directory lookups. I
> suspect the original FS designers did consider using a separate DB
> association for each directory entry, and decided it would be too
> inefficient.

Please don't give us that much credit.

The original FS schema had the directory entries as a massive skel
(like they are today) embedded within the NODE-REVISION skel (in the
nodes table). (That was back when file contents were also stored in
the NODE-REVISIONs, too.) When we realized how stupid that was, we
came up with the representations/strings tables, and moved the
contents items into those tables. Nobody had given much thought to
the efficiency of directory lookups in the skel system -- the idea was
to make things as simple as possible. Additionally, we thought
deltificaton would earn space saving on directory entries lists, which
tend to be quite compressible. But since the un-deltification costs
too much in time, we turned off deltification of directory entries
lists -- so we didn't even get the space savings we'd hoped for.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 29 03:56:12 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.