I always freeze Rails and unpack all my Gems... Do you guys prefer to add vendor/rails and vendor/gems to your .gitignore file?
Thanks, Elliott
To expand... All my gems are initially loaded via config.gem calls in their corresponding environment files.
i think choice your way.
I ignore them, but it would depend on your project and your own habits. If there are others working on the project you may want to put it under version control in case someone decides to change something in rails. For me, any hacks I do to activerecord or whatnot are put in a separate library so I'm never actually touching any of the rails code. So there are times when it could be useful, but you'll have to use your own judgment.
In general I keep vendor/gems and vendor/rails under version control, that way when I deploy I know what's going to be used without having to do extra steps.
However, I only unpack gems which are actually used for runtime rather than development, so I don't unpack gems like rspec, cucumber, webrat, etc. The config.gems statements go into the various environments/*.rb files, And other developers and I use things like
rake RAILS_ENV=test gems:install
to keep our development machines in sync.
Thanks for the feedback guys.
I am the sole developer on almost all of my projects and I have root access to the VPS environments that I deploy to.
Considering this I think a may give it a shot to just .gitignore vendor/rails and vendor/gems and then just run "rake gems:instal"l once I have my app on the production server.
Also, another reason I am thinking of doing this is that in the past when I had to change to a different version of a Gem is was kind of a pain to "git rm" all of the old gem's source from the app's repo.
Do this sound like a pretty solid plan to you guys considering my situation?
Thanks, Elliott
Another thing to think about is how critical is it that your app works exactly as planned on deployment. The more important it is, the more you should consider versioning everything.
I'm in a similar situation as you and am not freezing any of my gems. However, I have the versions specified in my environment file and have complete control over the VPS. Also, if something goes horribly wrong during deployment, its not costing us thousands of dollars in down time.
Good points. After setting up a non vendored deploy yesterday and encountering a few issues... I ended up going back to my usual vendoring strategy. However this time I took a good tip from Rick DeNatale and made sure I wasn't also vendoring and committing dev specific gems. Which I was doing before, doh.