BoxCycle is a Rails application that just switched to Git from SVN for version control and uses Capistrano to help automate deployment.

Problem: Deploy Updates Last Modified Dates on All Files

As shocking as it may seem, when you deploy a new version of your app, there is a good chance that Last Modified dates of all files will be updated to the date of deployment even though most of those files did not change.

Why Are Last Modified Dates Important?

In a word, caching.

Last Modified dates are used for Last-Modified and Etag headers which are used by the server to tell the browser if it can use the file already stored in the cache or needs to download the file again. They are also used by Rails for generating cache-busters – the query parameter it adds to images, javascript, and css. Cache-busters allow you to set Expires headers far in the future for files that don’t change often without worrying that you won’t be able to to update them should they change.

Expires headers are crucial since they allow the browser to use files in the cache without even asking the server if the files are still current (like it does with Last-Modified or ETag headers). Their importance is clear with Rails enabling cache-busters by default even though Expires headers require server configuration and won’t be enabled by many users. Rails cache-busters carry a decent performance hit since they must access the file system to get the modified date, but are still enabled by default since making setting Expires headers easier is deemed worth it.

But many default deployment processes will result in Last Modified dates being updated for unchanged files which means that users’ browser have to reload all static assets after every deploy significantly reducing the benefit of Expires headers as well as Last-Modified and Etag headers

Cause: Commands like cp, checkout, and clone Modify Dates

Odds are that your deployment process copies files or uses git clone or svn checkout. If it does, modified dates of all files will be updated.

cp offers options to retain modified dates. From everything I could find, SVN does not store modified dates in the repository and so there is no simple way of maintaining dates after you commit. Git seems to retain modified dates and this was the reason we switched to it, hoping this would solve this problem. While it may retain the dates, it did not solve the problem, since git clone sets new file dates. There may be a way to configure git clone to not overwrite the modified dates, but I didn’t find it before finding another solution.

Solution: Use :deploy_via, :remote_cache and set :normalize_asset_timestamps, false

In Capistrano we originally used :deploy_via, :checkout. With :remote_cache, Capistrano loads the latest version into a shared/cached-copy directory and fetches only the updates which allows the dates of unmodified files to remain on subsequent deploys. :remote_cache definitely works with Git and will probably work with SVN.

You may still have a problem since Capistrano may set all the dates for you. To make sure this doesn’t happen set :normalize_asset_timestamps, false in your deploy file.

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!