I recently switched my project over from SVN to Github. My reasons were varied, but a large reason was because I needed to create various branches to accomodate my ADD style of development (work on layouts for a bit, then switch to security, then switch to fine tuning my models). I also need to create a branch for productions servers, as well as a branch for my staging server, which is set up at home. The latter was a bit confusing at first, until I found a great tutorial here.

First, a couple of notes about my setup. I am the sole contributor to my (private) repository. Up until now, I have not had a need for this “forking” business that I see from time to time. In configuring up my multistage setup, I ran into an issue when I tried to use set :branch, "2.0" in my staging deploy.rb file. Even though I had created a branch for “2.0″ like so:
git branch 2.0
I was getting the following error:
`query_revision': Unable to resolve revision for 'invalid' on repository 'git@github.com:*****/******.git'. (RuntimeError)
This confused me for quite some time, until I found out that the set :branch isn’t referring to the branches that I had created locally, but to github forks. To create a fork from the branch, I simply had to do the following:
git checkout 2.0
git push origin 2.0

The origin bit is what does the magic. As soon as I refreshed, I was able to see the newly created fork in the github web UI, and my deploy recipe worked like magic. Brilliant!

Note: I still have to find out how this will affect my git workflow, but since the clone URL is still the same, it seems that I should still be able to continue with my current way of doing things.

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!