On Thu, Oct 02, 2003 at 01:05:52PM -0700, Kean Johnston wrote:
> I am sure this must be a FAQ, but I did look in the svn FAQ and didn't
> see it. I've found a few articles refering to using SQL as the backend
> database, but they mention some FS API rewrite. So please forgive the
Well, the FS *API* would not be changed. It's all under those covers.
> FAQ, but is anyone working on, or would anyone be interesting in working
> on getting SVN to use an SQL database for its data store. I am thinking
Plenty of people. It is just a matter of timing.
> of PostgreSQL rather than MySQL, mostly becuase it works on the platform
> *I* care about, and becuase I think its a more mature SQL environment
> and more likely to address SVN's needs.
I think the (major) current desire is to have a SQL-based relational
backend. Other DBs are certainly possible, but using an RDBMS is all the
All the BerkeleyDB-related code has been shifted into libsvn_fs/bdb/, but
there is still a *very* high coupling between the core libsvn_fs and the
code in bdb/. Work will need to occur on two fronts: bringing in a SQL
backend, and refining the core/backend APIs within libsvn_fs.
I think BDB is going to be quite a bit faster than any SQL solution, but a
SQL backend will bring adhoc queries (tho all I can think of are queries
for nodes with certain properties). A SQL backend would also enable SVN to
fit in with an admin's existing RDBMS backup/maintenance systems. For
example, if an admin has got an Oracle instance that is being regularly
backed up, then introducing an SVN 1.0 system would mean they've gotta
establish new backup procedures. Building SVN against Oracle would mean
that the admin doesn't have to come up with anything new -- they just
continue backing up their Oracle instance.
I'm all for it, but am not particularly interested in putting in time and
effort until 2004.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Oct 3 12:46:45 2003