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

Rails
1

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:

http://wiki.rubyonrails.com/rails/pages/HowtoUseRailsWithSubversion

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?

Thanks!

Sean

2

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}/
config/database.yml”
end

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

  • Jamis
3

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

Thank you!

Sean