cmpilato@localhost.localdomain wrote on 03/07/2005 01:01:00 PM:
> Graham Leggett <minfrin@sharp.fm> writes:
>
> > friedbert.widmann@hoerbiger.com wrote:
> >
> > > Can anyone tell me, how far is the integration of SQL databases for
> > > backends in Subversion?
> > > We are interested in using Subversion for our SCM - but managing a
Berkeley
> > > DB beside our existing Microsoft SQL Server isnīt our aim.
> >
> > We have chosen the fsfs backend for our system, which to date has
> > needed zero administration. I feel happier with keeping something
> > fundamental like source code in as simple a system as possible - to me
> > SQL is complexity that doesn't seem to add any value.
>
> The value-add for an SQL backend is mainly two-fold:
>
> * Trivial, customizable reporting. Write any query you want to
> suck whatever data out of the repository you so desire, munge it
> for human consumption, and you're done. No changes to core
> Subversion required at all.
This one would only be true if the SQL schema lent itself to queries. The
SQL backend could just as easily be a fairly unintelligeble mess of
binary-type data that happens to be stored in a database. I agree that
this is probably the major selling point of a SQL backend if a robust
schema design could be developed.
> * Enterprise buzzwordiness. Some folks (for reason I neither
> understand nor offer justification for) just don't feel good if
> there data doesn't live in the database system they're forking
> out the big bucks for.
I do not agree with you here. I think that a SQL database offers a lot of
possibilities. Just off the top of my head...
1) Backup/recovery. fsfs has a great story here, but when compared to
BDB, I think the issue is that many organizations already have tested
procedures in place for backing up and recovering their database. They
may also have a replicated cluster that supports hot switchover. I
imagine that BDB can be backed up and recovered quite well, it is just
that not many organizations will already be familiar with the process.
Thus it becomes a process that is always perceived as unique to
Subversion.
2) Scalability. I can picture a large hosting site like SourceForge
using a clustered SQL repository that is front-ended by a large number of
load-balanced Apache servers and getting very good response times. Since
you would get a robust "client/server" architecture for "free" with most
SQL engines, it offers a lot more possibilities for intelligently and
safely splitting the workload across machines.
3) Transactions. Most SQL databases will have a robust implementation of
transaction support. Subversion has done a great job implementing this in
the existing backends. In theory, it could be easier to implement and
also perform better in a SQL backend. Definitely just a theory though.
All this being said, when I originally came to Subversion a year+ ago I
was sure that I needed a SQL backend someday. The fsfs backend has made
me pretty much forget about it. That being said, I can still see that
there could be some advantages for larger installations.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 7 19:19:18 2005