With two branches it’s more easily to liberate small release, following the web2.0 principles

@RoadHouse: I used some time ago a similar approach as described by Joel Moss. But in the meantime I use a different approach: I have two branches (trunk and live) in my repository, in trunk I have the database configuration for my local environment, and in the live branch I have the configuration for the live server. So I do not have to add any logic to switch the database configurations.

@James Booker: Yeah, that’s the way I worked up to now. But now I am trying to move to an approach that uses only one connection on the dev server as I use the second connection rather seldom.

Live server has one database, one connection

Dev server has two databases, two connections. Default connection is what’s used for development work and such, daily use. Before shipping code to the live site, I take a dump of the live, production database, and import it into my development ‘test’ database, switch modes, and do one final run-through on a clean, yet valid database with the code I’ve just written – testing every feature I’ve modified (and if I have time those i haven’t – just in case!)

That way I’ve so far (fingers crossed) never had a hiccup with moving code to the production server

my 2 cents: i have the same opinion, im my projects i use the $default database for the development, this make my deploys more simples, because i dont have to change any code im my apps, just a ftp “put” =:]

btw, the Joel Moss´s solution it´s a nice aproach to this situation

Using the method described in my post above, I never nead to modify the database.php once it is setup.

My company uses svn and we all work remotely, so everyone checks out the entire app and runs it on their local machine. We have an app_model.php file in /app that checks to see what the host is (everyone edits their host file, so my computer is walker.dev and yours would be daniel.dev, etc) then it uses the db config matched up with that hostname

$walker = array(….)
$daniel = array(….)
etc

Then default is set to whatever the production environment will be. That way, everyone can continue to develop and easily deploy even after the first version of the app has gone live.

The username/passwords are more often than not different for the 2 databases (although they typically share the same name). Having the 2 different set ups makes it easy to facilitate this.