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

Re: Time to open SQL can-of-worms again?

From: Ed MacDonald <edmacdonald_at_hotmail.com>
Date: 2004-08-12 00:41:52 CEST

I too am merely a svn user, and likewise I have done a lot of DB work.
However I disagree with the suggestion that a relational DB has nothing to
offer subversion. Perhaps ad-hoc SQL queries are not important to SNV, but
I don't tend to let users of enterprise applications muck with the DB

A DB backend would provide a lot of functionality like transactions,
indexing, caching, backup/recovery, clustering, etc. This would allow the
SVN dev'rs to spend more time on the subversionishness of the application
instead of common plumbing.


----- Original Message -----
From: "m christensen" <dfs@xmission.com>
To: <users@subversion.tigris.org>
Sent: Wednesday, August 11, 2004 4:31 PM
Subject: Re: Time to open SQL can-of-worms again?

> Chris Beck wrote:
> > I noticed some chatting late last year about support for
> > Oracle/MySQL/SQL Server/PostreSQL. Nothing much happened. Since
> > there isn't much of a roadmap other than "We'd like to include
> > exclusive check-outs in 1.2" I thought I would raise the issue here
> > again before making an official enhancement request in the issue
> >
> > So. What is the status of work/desire for remote SQL repository
> > backends?
> >
> First off I'm nothing more than a user of subversion, not a developer.
> Secondly I have a lot of development experience, almost exclusively
> database related.
> My take on this knowing nothing of the background or previous
> discussions....
> Relational databases are great for dynamic representations of data and
> allow lots of way to
> look at and represent that data from a user prespective. This
> functionality comes at a cost
> which is worth it considering the flexibility.
> 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.
> Subversion preforms a very specific task from a database standpoint the
> flexibility complex SQL queries provide are useless.
> 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.
> 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?
> Marc
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 00:42:06 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.