SwitchTower and multiple database.yml files - how do you dea

Hi everyone,

What are other people doing with regards to database.yml being in
version control? My dilema:

I set up my rails app in svn using these instructions:


The part to note is where I ignore database.yml, allowing different
developers to keep their own database.yml without clobbering other
developers’ files. Sounds good. We typically use local MySQL
databases for local development and the production server uses a
remote db server running PostGres.

I just started deploying with SwitchTower, however, so, at first
checkout, there was no database.yml. That’s ok. I created it and all
is well.

Except when I deploy the next version. No database.yml! Uh oh.

So, am I doing something fundamentally wrong in not version
controlling database.yml? Should the production server only be
concerned with the production database (remote postgres) and the local
users be concerned with dev database (local mysql)? Should all
developers learn to play nicely with one database.yml file and set the
environments up accordingly?

I’m thinking this is the way, but it’s different than how I started
based on the above URL. What are other people doing?



I know others have solved this problem by using an after_update_code
hook that renames the real database.yml file:

task :after_update_code do
run “mv #{release_path}/config/database.yml.real #{release_path}/

Then, you version control the config/database.yml.real file (or not,
depending on how paranoid you are about your production DB password).

  • Jamis

Dang. So damn easy, I can see why I didn’t think of it myself.

Thank you!


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs