You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Glenn A. Thompson" <gt...@cdr.net> on 2003/05/19 14:32:39 UTC

[Fwd: Re: mysql for Subverison]

oops

Well,

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

Leeuw van der, Tim wrote:

>Hi,
>
>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 
Subversion.  

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

gat





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org