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

(SoC) SQL storage option for libsvn_fs_base

From: Edmund Horner <ejrh_at_paradise.net.nz>
Date: 2005-06-10 06:05:39 CEST

Hello everyone.

You might recall my on-again-off-again interest in storing Subversion
data in SQL; well, I've begun to think about it again and come up with a
new plan for doing it.

I'm going to submit this application to Google's Summer of Code, but I
thought I'd air it here first in case there are obvious things I'm
forgetting about.

Please comment by 14 June. :-)

Google "Summer of Code" proposal for the Subversion project

Edmund Horner


The storage layer of libsvn_fs_base will be abstracted, and an
implementation of an SQL storage option will be added alongside the existing
BDB storage option.


The benefits of this contribution will be a complete first SQL filesystem
backend, and the increased querying options that this will bring to
Subversion administrators. For instance, queries such as "which file
revisions have property foo?", or "which files are direct or indirect copies
of /trunk/README?" will be efficient and available as SQL queries. Another
possible benefit of the SQL filesystem is repository replication.


  * Storage layer abstraction in libsvn_fs_base, with the BDB storage option
    continuing to work as before.

  * Addition of an SQL storage option, initially storing data in a PostgreSQL

  * SQL functions for exploring the repository in an SQL client.


The BDB-specific functions (mostly in the bdb subdirectory) will be further
separated from libsvn_fs_base. A storage vtable will be created, which will
be used anywhere that the code currently calls a BDB function directly.
This vtable structure will be private to libsvn_fs_base.

An SQL implementation of the vtable will be created, with a very similar
structure to the BDB implementation. Schema changes will include using
integers for unique identifiers, replacing skels with individual SQL
attributes, and storing properties and directory entries as individual rows.

SQL functions for queries like those mentioned above will be written and
automatically created as part of repository creation. These functions will
be designed for human exploration of the repository filesystem.

Changes will occur in libsvn_fs_base, with the exception of additional
command-line arguments to svnadmin for repository creation (and the passing
of those arguments through to libsvn_fs_base).


Work will began full-time after my last mid-year examination on 18 June.
I have already spent some time recently improving my familiarity with the
existing filesystem backends. I can work full time on it until 4 July, when
the second half of the study year begins. After that I will continue work
at a slower pace.

If there are no contradictions in the design, I believe the work can be
completed within 2 or 3 months part-time.


I am a student at Victoria University of Wellington, studying Mathematics
and Computer Science. I will likely complete a Bachelor of Science degree
in the first half of 2006.

I have been a Subversion user since November 2002, and until now have taken
a mostly-passive interest in its development. I worked on a short-lived
MySQL-based filesystem backend in early 2004, and also contributed one small
patch (issue #1861 "library version checks", r10167) in July 2004.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 10 10:16:54 2005

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.