That is just the point, subversion has a 'DB Backend'.
It's Berkeley DB and already Provides transactions, indexing, caching I
assume and tools for backup and recovery
I don't think clustering is is provided but I seldom see a true need
for 'clustering per-se' there are lots of other ways to
provide redundancy and high avalibility.
Marc
Ed MacDonald wrote:
>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
>either.
>
>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.
>
>Ed
>
>
>----- 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
>>>
>>>
>tracker.
>
>
>>>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 01:02:20 2004