Semi-editable Files (eg config files) and version control - best practices?

Question

So, I killed the build today by checking in a config file. It knows where the server is (think SQL server or the like), and I\'ve been working against the server which runs

Answer 1

For each configuration file x, create a file that you do check-in called x.dist, which is the default distributed configuration. After the developers check out, have a script that copies each x.dist file to x, where they can customize x as much as necessary. This script can be re-run to update the files following major changes, or developers can manually merge in their changes.

For deployment, you can check in your live deployment files and have your start-up scripts refer to them explicitly (e.g. --config x.production).

This approach is used, for example, in how Wordpress is distributed (you must copy a template wp-config.php file) or in development projects that use autoconf (where the configure.ac is checked in but the configure file must be generated by each developer; a special configure file is built for distribution in tarballs at release time).