Best way to handle config files with subversion?

[eluser]simonwh[/eluser]
Just started using subversions, so bare with me

I've created a repository with my codeigniter project and it's all pretty good, there's just one obvious thing that I'm not getting.

The database access information is of course different on my local computer when I work with the "working copy" than it is on the live development and production servers.

How do I make sure that the config-files on the two live servers stays unique (so that my own config file that i may accidentialy commit does not override the one on the server).

What is the best way around this dilemma? I read something about svn-ignore etc., but seems like there would be a more obvious solution?

Also, anyone knows of a smart way of synchronizing mysql-databases that would fit this workflow?

Thanks in advance!

- Simon

[eluser]Phil Sturgeon[/eluser]
Here is how I manage config across environments.

The one downside being you need to have a private repository and trust whoever is looking at the code.

[eluser]BrianDHall[/eluser]
I use Phil's method. One additional way to 'secure' things if you need public SVN access is in your, say, database.php file use require_once() to include your own file that has your live database settings. Then in your subversion tell it to ignore/exclude that 'private' file for inclusion in the repository.

You could also just, more simply, use a sanitized database.php and config.php (or whatever you have for config files) 'blank' versions and submit those to SVN. Then set those files to be ignored by SVN, then replace them with your 'private' versions on your machine.

This way you can allow public checkouts of your code without giving away your private passwords and config information.

For synchronizing mysql databases, I had a thread about this ahwhile ago: http://ellislab.com/forums/viewthread/133668/

Now I dump my db manually with schema only, then occasionally do a data dump - all files managed by SVN.

An entrprising type might use a script, macro, or cron to automatically dump a backup of the database regularly to help you keep up with data-only backups, but some people advise to not use SVN for tracking data changes at all and prefer something more like a dated tarball method.

I've been sufficiently satisfied with manually dumping the data and doing a Commit on them either whenever I change schema or every few days if there has been a lot of site activity I don't want to risk, or if I'm about to alter the live server database.

[eluser]simonwh[/eluser]
Thanks a lot guys!

I'll go try Phil's method, seems to be all I need.

About the database, I think I'll do something along the lines of what you do Brian. Just dumb the scheme and import it whenever I do major changes.

[eluser]srisa[/eluser]
I use templates, eg. config.php.tpl where all config options are empty. When user checks out from the repository he has to copy it as config.php and put in values for all the options. All additions/deletions are done to config.php.tpl and svn users will have to modify their config.php accordingly.
--------------------------------------------------
Edit: Notify all users that config.php is not be committed to the repository.

[eluser]n0xie[/eluser]
[quote author="srisa" date="1257982587"]I use templates, eg. config.php.tpl where all config options are empty. When user checks out from the repository he has to copy it as config.php and put in values for all the options. All additions/deletions are done to config.php.tpl and svn users will have to modify their config.php accordingly.
--------------------------------------------------
Edit: Notify all users that config.php is not be committed to the repository.[/quote]

We do the same for the database config file. We rename our files to <name>.default.php. Reason being that if you work with several developers, they will all have their own database connection/setup, their own config etc. This way when you automate export to the testing/uat/live server, you NEVER run the risk of accidentally overwriting the server config.