Rails - Jan 2006 - SwitchTower and multiple database.yml files - how do you deal with them?

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

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

On Jan 24, 2006, at 2:31 PM, Sean Hussey wrote:
> 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

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

Thank you!

Sean

On 1/24/06, Jamis Buck <jamis@37signals.com>
wrote:
> 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
>
> On Jan 24, 2006, at 2:31 PM, Sean Hussey wrote:
>
> > 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
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>