The Death of SvnRecord?
Of course, SvnRecord was too good to be true. After a week of implementation, using Subversion as a backing store for a web app seems infeasible for anything non-trivial. Problems I ran into:
-
The Svn::Ra protocol layer is gimped. As far as I can tell, you can’t ask across the network: “List all the (versioned) properties of this file at revision n.” It seems everything useful requires the Svn::Client layer, which works with a local working copy on disk to do most useful things.
Because of this, to get decent performance for operations like that, you’d have to setup a ramdisk. This makes deployment a pain, and adds truckloads of platform dependencies.
The documentation sucks. I had to spend my time flipping through the comments in the bindings, the underlying .h, the svn client itself, 2 books, and all the unit tests to get anything done.
The Ruby bindings suck. There’s a dozen alias functions that do the same thing, all the underlying “do_something” and “do_something{2,3}” replacements are still there. It’s easy to segfault the bindings. The user has to deal with most of the underlying implementation of library, using classes like Svn::Ra::Callbacks to mirror what the C library is doing. Ruby shouldn’t be passing around auth_batons and such.
Memory. Just opening an Ra session adds 20M to RSS. Fetching a few files bring the processes to 130MB. This is probably a bad interaction between Ruby’s GC and Subversion’s APR pool memory management. I could find no way to flush the pools, and as there’s no docs, I’m done looking. Having 4 mongrels on one server doing this would be insane.
I’m mostly disappointed because SVN isn’t the old legacy project it feels like. It’s a pretty young project (in Unix terms), and I expected it to have less gotchas and problems.
Of course, I could look into other version control systems, but the whole point was that Subversion is well-understood and has been installed by thousands of people. I guess I’m back to timetravel tables in PostgreSQL.