The world is spinning when it comes to the Acts as Subversioned plugin. Yesterday, I was about to release version 0.2; I couldn’t, but it may not have been a bad thing.

So far (this includes v. 0.2), the plugin does two things: Lets you revision ActiveRecord objects using a Subversion repository, and lets you call Subversion-only functions that add value to your Ruby on Rails project. What’s really implied in that statement is this: The plugin alters the MySQL adapter for ActiveRecord at runtime, and adds in code that “does stuff” to the repository. Since, in “doing stuff,” the repository becomes the heavy-hitter for data within the models that are subversioned, the MySQL database simply turns into a cache holding the data that is the most up-to-date. Although this sounds like a good thing, is it really needed?

Through some emails with Bill Horsman, I stumbled upon a new direction that I think (and want) the plugin to move toward. Instead of “adding code” to the MySQL adapter at runtime (which, unfortunately, makes this a MySQL-and-similar only plugin), I would make my own ActiveRecord adapter that would connect directly to Subversion. What this means is that, along with the MySQLAdapter, and the PostgresSQLAdapter, and the OracleAdapter… there would be a SubversionAdapter. There would be no more of this “adding code” mantra; instead, it would be Subversion through and through.

To give you more of an idea what I’m talking about, instead of saying “adapter: mysql” inside of your database.yml, you’d now say “adapter: subversion”. The model for programming using a Subversion repository would be different, but I’m pretty sure I can replicate all the “find_by_X” functions as well as the id-based model structure, in (hopefully) O(1) time.

The problem with doing things using the Subversion adapter is that you’d only have access to one type of data store — this means you have to scrap the MySQL database and use Subversion only. This could lead to speed decreases (I’d guess that read/write speeds for Subversion are slower than that of MySQL), as well as a loss in functionality (complicated queries are most likely out the window). On the other hand, the benefits this would give to wiki-based programs would be enormous, as would the ability to see (and possibly measure) how data changes in your program over time.

How does this affect you/change your expectations of what this program is, and/or was? Is this “adapter style” more to what you were expecting in the first place, or less? Does it come with too many side effects?

My inclination is to go along this adapter-route, and see where it leads. Choosing this path would most likely 1) totally change the face of the plugin, and 2) affect what I release now, because #1 would make releasing less worthwhile.

Any thoughts? I don’t claim to be an expert at either Subversion, MySQL, or ActiveRecord, so any insight you can give me would be greatly appreciated.

PS: I’m still working things out with RubyForge. Even if things are going to change drastically, I’ll still release the new code as soon as I am able to.

Update, 4/23/2007: There’s no files on the RubyForge project site yet. I think I triggered a pretty nasty bug; now I’ve got to talk to support…

Okay, okay. I know I told all of you that I wasn’t releasing something for the next couple weeks. Well… I am. I thought about it for a while, and realized (as most programmers do) that I was pretty ambitious and promised too much for a single release. So, instead of giving you one big release packed full of features, I figured what the heck? I’ll give you what I have.

There’s some big things in this release, although they weren’t what I was expecting. First, the wrapper (and the plugin) now supports BDB filesystems. Personally, I don’t think BDB is better than FSFS (there’s some debate on that), but if you like it, you can use it. Second, the wrapper has undergone some big changes. I’d take a look at the changelog to get all of them.

The plugin has gotten some new stuff as well, but arguably not as much. It has gotten some new parameters, as well as some basic diffing support. Its internal structure has also changed to reflect changes in the wrapper.

You can find the new release at the RubyForge project page.

Overall, I would call this release an intermediate release. Although this isn’t everything I want it to be (yet), it should give you a bit more to play with. Enjoy!

That’s right — I’ve finished the first public version of my plugin for Ruby on Rails!

Here’s the project link: http://rubyforge.org/projects/actsassvn/

For those of you that downloaded my svn_repos.rb from a previous post: get rid of it! An updated version of that file is released in the above project.

What you get with this plugin:

• A sweet way to revision ActiveRecord objects using a Subversion repository,
• A fixture-style test harness for using repositories in unit tests,
• The above mentioned wrapper class for interacting with repositories,
• and automatic creation of environment specific repositories, handled by the plugin itself.

Once again, check it out at the RubyForge project site!

Note: Some documation is provided within the files themselves. I’m working on writing more user/technical documentation as well as trying to get RubyForge’s wiki to work with the project site (for some reason, there’s trouble). I’ll post again in the next week or two and let you know what’s up.

And…

Version 0.2 is in the works. I’ve got some ideas I’d like to add to this plugin to round out its features (mainly housekeeping of the repository itself, as well as diffing support and file locking). I’ll keep you posted.

Thanks for the interest!