To give you a little bit of background on my setup, I am using Capistrano to deploy to two servers, both of which are running Phusion Passenger.  One server is on a shared host, along with the SVN repository, and the second server is inside of a private network with a sub-optimal internet connection.  Both servers share a common database.  I ran into an issue running “cap deploy”, because it was trying to copy the entire application over ssh to both servers every time.  This wasn’t a large issue for the shared host, but the server in the private network would keep hanging after it got past a certain point.  This all took me days to figure out, because capistrano give very minimal debugging/logging information, and the error messages changed every time, usually letting me know that the I/O stream had closed.

I first set this scenario up using the Agile Development with RoR book, but since I was using an outdated PDF, turns out I wasn’t using the optimal setup.  Originally, the book called for the following line in my config/deploy.rb file:

set :deploy_via, :export

The idea here is that you want to export the project from the SVN repository,  but leave behind all the unnecessary subversion .svn junk.  Seemed reasonable enough to me.  However, in the updated PDF, they made a subtle, but gamechanging alteration:

set :deploy_via, :remote_cache

What this does, is it actually checks out a version of your project into shared/cached-copy on the target server(s), and going forward only runs an SVN update command, which only updates the files that have been changed.  Capistrano then uses this copy to deploy your code the same as before.

It seems like the obvious choice, and now that I know where to look, there is plenty of information about it.  But if you are stuck waiting for an hour for cap deploy to finish, or are getting random errors, it’s hard to find an answer online.  In my case, I actually manually checked out my code into the shared/cached-copy directory on both servers, as I was tired of capistrano screwing it up.  Once I got the initial code in there, further cap deploy’s take only 1 minute or so, compared to 30+ minutes previously.  Sweet!