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

Re: (SoC) SQL storage option for libsvn_fs_base

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-06-14 18:09:08 CEST

Edmund Horner <ejrh@paradise.net.nz> writes:

> 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.

So, in reviewing your new plan, it strikes me as the same plan that
Glenn A. Thompson (who likely cometh hence from the ether, but for a
moment, as I didst utter his name) has been talking about
on-again-off-again for ... gosh, years, now. Don't get me wrong --
that's a good thing!

> 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.
> Benefits:
> 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.

Blah blah yadda yadda ... :-)

> Deliverables:
> * 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
> database.
> * SQL functions for exploring the repository in an SQL client.

Okey dokey. You forgot one, though:

    * Doing all this without noticably negative performance impact on
      existing backends.

[Rest of the proposal trimmed]

I've been recently warned against referring to a generic SQL backend,
as the flavors of SQL-ready databases differ wildly enough that you
really need to make special considerations for each one in order to
harvest the real utility of any of them. So, unless we really think
we can pull off a generic SQL backend that just works with all SQL
databases, let's call this one what it is intended to be -- a
postqresql backend -- shall we? Just trying to eliminate confusion
and properly set expectations of the receiving public.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 14 18:12:14 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.