I haven’t done a programming related blog entry until this one.  Why?  First, I want to keep this blog focused on BoxCycle and environmental issues.  Second, I haven’t had much time, as is evident from lack of posts on environmental issues.  Finally, I haven’t run into much that I couldn’t find an answer to with a few searches and I am not fond of duplicating effort just to get a post up.  This time I think I have something to contribute to the Ruby on Rails community.

The issue is updating plugins.  Initially, I simply did ‘plugin install’ and checked them into my svn repository not thinking much of it.  My guess is, this is what most beginners to Subversion do.  In passing I saw things about svn:externals, but figured it was advanced stuff and I’d sort it out later.

When it came time to update some of the plugins I did ‘plugin install’ again, and didn’t think much of it, again.  That is, until I went to checkin the project.  Subversion refused.  It took me a while to figure out what’s going on and a lot of trial and error to be able to check in the project at all.  I now know exactly how to do it:

1. Delete the directory containing the plugin
2. Checkin changes
3. Install the new plugin
4. Checkin changes

Quite annoying.  Even worse if you made changes to the plugin code.  Why is this necessary?

Subversion keeps state in hidden .svn directories in your local copy.  It can’t checkin directories that are missing .svn folders because it can’t figure out their state.  ‘plugin install’ removes the directory tree when it reinstalls the plugin.  The only thing you can do is first checkin a version without the directory and then add the directory back in the next commit.  Some good links on the topic: http://railsforum.com/viewtopic.php?id=24882 and http://stackoverflow.com/questions/119006/what-should-i-do-with-the-vendor-directory-with-respect-to-subversion .

Once I figured out the issue, I understood svn:externals and found tools like Piston to make management easier.  However, by then, most of the Rails community has moved to Git version control which doesn’t work well with svn:externals or Piston.  Piston has been promising to make a Git compatible version, but for much of BoxCycle’s existence it hasn’t occurred.  Plugin updates have been a huge thorn in my side.

With large changes to Rails 2.3.2, most plugins needed to be updated.  I was very excited to see that Piston 2.0.2 has finally been released and ‘gem install piston’ actually installed the right version, which has not been the case for me with 1.9.x releases.  However, I did run into installation issues on Windows which took me a while to resolve.  Sharing the solution is my primary motivation for this post.

So keep the following in mind when you install Piston 2.0.2 on a Windows XP machine (I presume Vista is similar):

• After ‘gem install piston’ type in the ‘piston’ command.  If you get errors, read them carefully.  Dependencies don’t seem to be well defined for the Piston gem and I had to install a number of gems separately before the ‘piston’ command displayed the usage help screen.
• You need to have Git installed for Piston to work with Git repositories.  I installed  MSysGit . 
• With Windows you are likely using InstantRails which runs in it’s own isolated environment.  This means that Piston will not be aware that MSysGit is installed.  You need to update the InstantRails PATH to include Git.  Edit c:InstantRailsuse_ruby.cmd to have the PATH line include c:Program FilesGitcmd (or whatever your path to Git is).   Also update the use_ruby.cmd template in conf_files directory.

Once I got Piston working I deleted existing plugins, hopefully for the last time, and did a checkin.  Then I used ‘piston import’ to install new versions under Piston’s management.  I am quite relieved to not have to dread updating plugins again!