To track or not to track: files to remove from SVN while using Capistrano

Background

This article assumes that you know what Subversion(SVN) source control is. I was trying to figure out how to deploy rails applications using Capistrano. I think of Capistrano as a fancy replacement for FTP, but of course it’s much more than that. Capistrano is a deployment tool that acts as a liason between your local development box, your SVN repository, and the web server, and handles all the pesky details for you when you want to deploy to your web server from your code repository. For example, after typing “cap deploy” on your local machine Capistrano will:

  • download all the code from your SVN repository into your production server
  • log into your remote machines (web server and repository)
  • remove files on your production server that you don’t want to have uploaded.
  • create symbolic links in your rails deployment to system web server specific copies of the rails file (like dispatch.cgi)
  • remove old temporary files or previous deployment files

It is implemented in Ruby and runs on your development machine. Although it was originally developed for deploying RoR applications, you can use it for fancier things like managing your server farm on Amazon’s EC2. My development box was running Rails 1.2.2 and my web server was running Rails 1.2.3 at the time of this writing, and my particular Capistrano configuration makes symbolic links to core rails files to remedy the difference in these two Rails versions. In the discovery process, I realized that some files needed to be removed from SVN. Here is what I came up with. I hope it helps you. I’m using railsplayground.com, shared hosting, dispatch.cgi.

In general there are two different ways to use SVN:

  • Track as few files as possible.
  • Track as many files as possible.

I’m basically going for option 2. We’re trying to track as many files as possible, but we’re not going to the extreme and tracking each developer’s configuration files.

What not to version:

Some system files need or should be left unversioned. There are 4 possible reasons why a given file should not be versioned:

  • The file is server-specific, e.g. a configuration file for that particular machine.
  • The file is developer’s box-specific.
  • The file is Rails-version/Rails installation-specific. Ie. If the Rails version of the web server didn’t match that of the developer’s box, then the web application would crash or not start-up.
  • It’s impractical or uninteresting to version the file, e.g. log files that bloat up very quickly, or /tmp session files.

Instead they will be symbolically linked to a railsplayground.com (RPG) version in the /home/your_app/Some system files need or should be left unversioned. There are 4 possible reasons why a given file should not be versioned:

  • The file is server-specific, e.g. a configuration file for that particular machine.
  • The file is developer’s box-specific.
  • The file is Rails-version/Rails installation-specific. Ie. If the Rails version of the web server didn’t match that of the developer’s box, then the web application would crash or not start-up.
  • It’s impractical or uninteresting to version the file, e.g. log files that bloat up very quickly, or /tmp session files.

Instead they will be symbolically linked to a railsplayground.com (RPG) version in the /home/your_site/your_app_production/shared/ directory during the Capistrano :after_symlink task.

  • /config/boot.rb <- system specific
  • /config/environment.rb <- system specific
  • /config/database.yml <- it contains information specific to development machines on programmers’ laptops
  • /config/environments/development.rb <- specific to development machines
  • /log/* <- these files get bloated fast so we shouldn’t version these. Also, changes are just appended to the bottom of the file. development.log shouldn’t be versioned because it’s specific to each developer’s machine. In particular these /script files should be excluded from SVN control:
    • /log/development.log
    • /log/test.log <—- put a symbolic link to this in /your_app_production/shared/log/
    • /log/production.log <—- put a symbolic link to this in /your_app_production/shared/log/
    • /log/server.log <—- put a symbolic link to this in /your_app_production/shared/log/
  • /script/* <- these scripts can differ from one rails version to the next, so they should be kept in sync with the RPG server’s version of rails. In particular:
    • /script/about
    • /script/breakpointer
    • /script/console
    • /script/destroy
    • /script/generate
    • /script/plugin
    • /script/runner
    • /script/server
    • /script/benchmarker
    • /script/profiler
    • /script/inspector
    • /script/reaper
    • /script/spawner
  • /public/dispatch.cgi <- system-specific/rails version specific.
  • /public/dispatch.fcgi <- same as above
  • /public/dispatch.rb <- same as above
  • /tmp/ <- stores session data, which is not something we care about to version.

NB: I recommend that we version /public/.htaccess, because that’s where we control whether or not to use fast CGI or regular CGI, and we might want to roll it back in case we mess up.

Posted by David Beckwith on Tuesday, April 24, 2007