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

[Fwd: Re: mysql for Subverison]

From: Glenn A. Thompson <gthompson_at_cdr.net>
Date: 2003-05-19 16:32:39 CEST



I guess I'm becoming the official responder to SQL queries (pardon the pun).

Leeuw van der, Tim wrote:

>SubVersion is written to the Berkely-DB interface. It doesn't use any SQL
>statements anywhere. It will therefore be a lot of work to replace the DB
>implementation with any kind of relational database.
Yes but doable:-)

>I don't know what the value will be of porting to MySQL; SubVersion needs
>transactions and if you want MySQL to support transactions you have 2
>choices: data is stored in either InnoDB tables or .... Berkely-DB tables.
I don't understand this statement. I'm quite impressed with InnoDB
tables. How many txn table types do you need? :-)

>So you'd effectively replace the interface to Berkely-DB with another layer
>that talks to the same Berkely-DB and you're hoping that this extra
>layering, with it's overhead and inter-process communications, will bring
>sufficient amounts of efficiency through caching to win against direct
>integration with Berkely-DB?
So don't use Berkely-DB table types. InnoDB is pretty much *the* table
type to use if you need transactions.
And raw performance isn't usually a reason to go to a SQL DB. It is a
dynamic model after all:-) However, long term there are plans to add
features that *may* be better served by a SQL DB.

>If you create an SQL layer in SubVersion you can perhaps set it up to talk
>to other SQL databases, such as Oracle, DB2, PostgreSQL, whatever you like.
>Then you can benchmark if that perhaps gives you any extra performance.
Tim, you keep mentioning performance. I didn't see that in the original
posting. There are other reasons that make it a good choice.
 Replication, backup and recovery, I/O management. SQL products tend to
be mature in these areas. And there is that flexibility thing. Also,
SQL DBs that do consistant reads based on multi-versioning may provide
performance gains for highly contended repos.

I noticed that you have a UNISYS e-mail addr. If you want performance,
get them to port DMS 1100 to C. Now we are talking performance! ;-) I
believe that a "CODASYL/Network" DB would be an interesting choice for

But seriously, I'm workin' on it. Really I am:-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 19 16:35:15 2003

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

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