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

[Fwd: Re: (SoC) SQL storage option for libsvn_fs_base]

From: Glenn A. Thompson <gthompson_at_cdr.net>
Date: 2005-06-15 01:52:04 CEST

Whoops I sent this to John only

Hey Guys,

I'm in the process of moving back to Colorado so I haven't been keeping
an eye on Subversion.
I have a whole bunch of low level code which uses apr_pools etc. It's
at least two years old though.
I'm going to be shuting down all my boxes in the next 24 hours, I should
be back up in CO in a week.
Is the SQL work topping the priority list?

I doubt I'll be able to help much in the next 30 days but I will dig out
that code next week if folks are in a hurry and want to take a look at
it. I'm pretty sure I have it on two boxes and tape.

gat

John Peacock wrote:

> Charles Bailey wrote:
>
>> Granting that the details of connecting to the DB and SQL extensions
>> differ, it'd be nice if a prototypical SQL backend tried to stay as
>> general as possible (e.g. sequences are available in most
>> commonly-used RDBs, but table inheritance isn't), to make it more
>> possible to port the result from Postgres to, say, MySQL.
>
>
> That's part of avoiding premature optimization. Any initial SQL
> backend should have a very-low-level layer which deals with actually
> communicating with the database and a slightly-higher-level layer
> which performs as generic a SQL query as possible (no proprietary
> extensions). Only when the first pass is complete will it [hopefully]
> become obvious whether or not performance issues require use of DB
> specific extensions.
>
> My $0.02...
>
> John
>

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