views:

34

answers:

1

I've posted a couple other questions during this process, but I have a better idea of what I'm trying to do so I thought I'd ask about that.

I've inherited a Rails 2.2.2 application, which is currently running in production form on a server I have access to. I'm trying to port that application over to my server, version control, etc. I first tried to copy over the source code and get it running under Rails 3 and the latest versions of gems, but that's proved to be much more difficult than I thought it would be. It seems like the best solution is to simply use the same version of Rails and other gems that the current system is using, and port over the application as-is.

So I'm wondering what the best way to do that is? I can put the source in my version control system and set up Capistrano and Passenger the same way as they are now. The issue is getting all the gems over in the same version. I've heard about freezing Rails and freezing gems, but a lot of the tutorials on it look a bit outdated. Is it safe to freeze the gems on the currently-running production server, or should I just get a list of the gems and their versions and manually install them all on the new server I'm porting over to?

Edit: I followed tadman's suggestion and set up a Gemfile with all the gems and latest versions installed on the production server, but now I've gotten into a versioning mess with those, for example:

Bundler could not find compatible versions for gem "ruby2ruby":
  In Gemfile:
    merb-action-args (= 1.0.8.1) depends on
      ruby2ruby (>= 1.1.9)

    ambition (= 0.5.4) depends on
      ruby2ruby (1.1.8)

The production server has sometimes up to 4 versions of the same gem installed, but Bundler seems to only want to handle one version of each. Is there an easy way to solve a situation like this, or is it back to looking into freezing gems in production?

Edit 2: I wound up removing versions from all gems except for rails and doing bundle install. So far, it seems to be working even though all the versions aren't matched exactly.

+1  A: 

Switching to Rails 3 might be a serious headache, but packaging up the historical versions of the gems can be significantly easier. To a degree this is made easier by bundler where you can declare the specific versions you need in a Gemfile for your application. While this is the de-facto method used in Rails 3, it is platform agnostic and can be used on any version of Rails as a distribution mechanism.

You can usually determine the version of gems used with gem list as, unless otherwise specified in config/environment.rb the most recent version is selected automatically. It is easy to transform a gem list into a Gemfile.

tadman
Rather than using the (huge) list of gems from `gem list`, I went through that list grepping for gems in my codebase, and deleting that ones that weren't used. That brought the bundle down to a more manageable size.
jrdioko