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:
>
> http://web.mit.edu/ghudson/thoughts/diagnosing
>
>(since the fifthvision list archive is no longer available) and the
>response is at:
>
> http://web.mit.edu/ghudson/thoughts/undiagnosing
>
>Enjoy.
>
>
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
course).
* 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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 29 23:39:43 2004