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
Received on Mon May 19 16:35:15 2003