m christensen <dfs@xmission.com> wrote on 08/11/2004 06:31:08 PM:
>
> What would this 'flexibility' buy subversion?
> The speed penalty from what I've been told in the case of berkeley DB
> VS relational databases is 10-100 TIMES.
> Subversion already has a reputation for being slow. By definition
> everything it reads or writes goes to that database,
> do we want that to slow down by several orders of magnitude.
The same thing was said about a native filesystem implementation, and the
opposite appears to be true now that one has been created. The bottom
line is that until an implementation is created, this is all just
speculation. Personally, I think my OS/400 database which is spread
across 18 15K RPM SCSI drives will hold its own.
>
> Subversion preforms a very specific task from a database standpoint the
> flexibility complex SQL queries provide are useless.
I disagree. One of the reasons I think a SQL implementation would be
useful is that it would allow for ad-hoc querying and reporting which is
currently missing from Subversion and present in many commercial tools.
>
> The only 'advantage' generic database support would provide would be to
> allow people to "muck" with the data directly.
> That is a bad idea IMHO.
Certainly, but just because BDB is not accessible does not make that a
feature of BDB. A certain amount of common sense will always apply.
>
> Subversion provides an easily automated command line interface and APIs
> to provide an abstracted interface to the
> logical information describing a repository, what more would anyone
> need? What can of worms does that open?
>
I think there are a lot of benefits a SQL implementation could bring. I
have already mentioned some, here are some more:
1) Backup and recovery. Most enterprises already have this taken care of
for their databases. Subversion could slide right into this framework.
2) Stability. A SQL implementation is not inherently more stable than a
native file system or BDB, but many enterprise managers will still feel
more comfortable with one.
3) Scalability. All sort of options would be opened up, from clustering
and high-availability, to separating the Subversion "application server"
from the physical database server.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 03:07:34 2004