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

Re: A quick-and-dirty MySQL fs backend

From: Glenn A. Thompson <gthompson_at_cdr.net>
Date: 2004-02-19 18:33:46 CET


Edmund Horner wrote:

> Thanks Glenn, that was quite an encouraging post. I've read it all but
> haven't replied to every part of it. My plan is to get some feedback
> about where I'm at (as described), just to make sure I'm not doing
> anything *outrageously* reckless.

It's only reckless if it gets slammed into the baseline without review.
That will never happen;-)

> Glenn A. Thompson wrote:
> > Originally, I wanted ODBC to be the API plugin point for
> > supporting more than one DB. After some work I decided that it would
> > not be the correct choice. However, the first, and only working,
> > adapter is the ODBC adapter. I did work on the Oracle and Mysql
> > adapter. All of it was based on a very old version of Subversion and
> > APR. So I need some time to get it working.
> Someone (chipig) suggested quite recently on #svn that I use something
> called libdbi (http://libdbi.sourceforge.net).

Yes, I saw that a little while back. At first glance, I sure liked it.

I wanted something that used APR (remember the mem usage issue), and
something fairly light weight. Plus, I'm not sure if it was around when
I started my original work. But I would check it out if I were you. If
you look at ODBC/JDBC or whatever, it has a great deal of support for DB
related metadata and other convenient things. This is great stuff for
applications that require runtime schema discovery. A report generator
is a good example of something that needs this type of capability. IMO
Subversion needs none of that. So I tried to keep my work focused on
writing, executing, and configuring hand written queries.

> > I'm in the middle of a "S... storm". The most I can do right now is
> post
> > my pluggable document somewhere. BUT Please don't let this
> conversation
> > get in the way of 1.0. I use and love Subversion and don't want to see
> > it veered off course by such a large discussion.
> You have sand storms where you are?


> Please post your Word doc. And I agree with you about not knocking
> Subversion from it's 1.0 (and 1.1 ?) goal. I just need a bit of
> feedback to continue work on (for the time being) casual project.

I was just looking for it. It's not in my Subversion repos. Shame on me.
I have it backed up in several places though.

> > You shouldn't *have* to use "for update" when auto_increment columns
> are
> > being used. Research sequences. As in "Oracle" sequences. There are
> > tricks for approximating them in MySQL. You can't get all the way
> > there, but you can get close.
> Yes, ACIDity does seem to be unnecessarily complicated with
> MySQL/InnoDB. And I will switch to using AUTO_INCREMENT.

It has nothing to do with MySQL. It's SQL DBs in general. The InnoDB
impl is quite good from what I've seen so far. And I can't say I agree
with the word "unnecessarily".

I will post my doc at http://www.cdrguys.com/subversion/index.html later
today. But, like I said, I'm buried. So please don't expect much more
from me right now. I have enough guilt about my lack of Subversion work:-)

> And thank you to the Subversion team--I've noticed an awful lot of
> commit activity lately; so things are obviously getting polished to a
> nice gleam!
> Let me repeat that I'm not looking to change Subversion for quite some
> time yet, if ever. If you like you can think of my effort as a little
> "comic relief".
Not at all. From what I've seen, the people on this list appreciate any
and all work being done. Whether it makes it in the baseline or not.

The only other advice I can give right now is: round trips to the DB
kill performance.

Again, way to go folks. I'm very excited about 1.0.

Over and Out,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 19 18:41:19 2004

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.