Greg Hudson wrote:
>Some of you may have run across the "Diagnosing SVN" Tom Lord post at
>some point. If you do a google search on "diagnosing svn", you can
>find indications that at least a few people saw it as a nail in the
>coffin for Subversion.
>Ben has been working on collecting together anti-Subversion commentary
>(like this and the bileblog entry), and since I don't think
>"Diagnosing svn" deserves quite so much credence as a Subversion
>critique, I wrote up a response for that purpose. If people here are
>interested, the original is at:
>(since the fifthvision list archive is no longer available) and the
>response is at:
Did so. :-)
I even have two comments:
>5. Taking a step back
> "If a team went away for six months and came back with SVN as it
> works today, I think it'd be pretty easy to say: 'That's a great and
> even useful prototype. It definately proves, at least
> schematically, the idea of using a transactional FS to back
> revision control. There are clearly some bad choices in the
> implementation, and clearly some important neglected revision
> control issues that competing projects are starting to leapfrog you
> over. And there's a heck of a lot of code here for what it does.
> Let's suspend development on it for a little while, and invest in
> a design effort to see how to get this thing _right_'."
Much as I admire Tom, I think this is a point where he totally fails to
understand the realities of software development. I know any number of
(commercial and open source) projects where somebody came up with Tom's
argument relatively late in the development cycle -- the way he did --
and management (or equivalent) let itself be talked into taking a step
back. The result has, in my experience, invariably been either failure
of the project or horrendous cost and time overruns (which, in the
commercial world, is sometimes even worse).
>But by and large, the point is valid: as long as Subversion's back end
>is tied to Berkeley DB, its reliability will suffer. You can run out
>of locks. An improperly terminated operation can cause the database
>to require recovery. Access to the database from multiple Unix
>accounts requires proper umasks or the database appears to become
>corrupted. The database will not work properly over a remote
>filesystem. Moving the database from one platform to another results
>in cryptic failures.
These points are valid as far as they go, but:
* You can run out of locks in an RDBMS, which usually results in
randomly aborted transactions
* Bringing up the permission problem is a bit unfair, because
RDBMSes don't even allow access to the database except through a
server. At a minimum, you should use ra_svn as a base for access
method comparisons. ra_local was never meant to be used in a
serious installation. A similar point can be made about the
"remote filesystem" argument; I have yet to see an RDBMS that will
work with anything but local storage (SAN would count as local, of
* Nor have I seen a RDBMS that can have its data store migrated to a
different platform without a dump/load cycle or equivalent.
Yes, administering BerkeleyDB is not easy, and it's partially our fault
for not implementing a bullet-proof automatic recovery scheme. However,
I'll take svn repos administration over Oracle admin any day.
I think the main point against BerkeleyDB as it's used in Subversion is
that it's very hard to do custom queries, storage optimizations, etc.,
which mainstream RDBMSes have tools for.
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 29 23:39:43 2004