How should I handle website config files when importing a site into a SVN repository?

Question

I'm starting to use SVN repositories for all of our websites and wanted to know what the best practise was regarding website config files.

Should they be stored in the repository? The problem is the configuration of the websites need to be different for the working copies than that of the live sites. If I edit the config file for a working copy so that I can test on my machine when I commit back to the repository the config file will be updated there too and could then potentially get uploaded to the live site.

What do people generally do with config files, is there a way to tell SVN to skip config files when performing commits etc?

Answer 1

Generally, it's best to put config files into version control if they store significant information.

If you're talking ASP.NET sites here, I'd definitely place the config file in SVN. You can play a few tricks in ASP.NET config files using inheritInChildApplications and allowOverride (see How to: Lock ASP.NET Configuration Settings) which may allow you to force a local debug version to use different settings from the final production version despite using the same config file: just mount the website as a sub-directory in the local debug IIS and lock a few sections you wish to override. And of course, you could just include two config keys for particularly tricky bits and check in code which to load.

In general, it's good practice to make deploying anything from SVN a process involving as few manual steps as possible. That makes it more likely you'll do it correctly under time-pressure, and it makes disaster recovery easier to boot (say, when your datacenter springs a leak and you want to install the web site on some temporary box until you've got those backups sorted). Ideally, an svn checkout or export with at most a compile should suffice to get the web site up and running. I include even binary dll-dependencies directly in svn (stuff like javascript compressors and whatnot) so it'll run without requiring a bunch of custom library installs on the server, and compile on a dev machine with just msbuild.

For PHP, the principle is the same. However, you'll need different tricks. For instance, you might write the config file such that it checks some global system environment variable, and then overrides selected settings if it's a dev-machine. For instance, I've a setup similar to this where I check the IP address; all dev-machines are in a particular IP-block; unless a machine is in that IP block, it's considered a production machine (which doesn't enable various tracing etc. options). You could also check the host name, or simply any old environment variable which all developers agree to set on their development machines.

Answer 2

If the variables between your dev/live environments are limited to just connecionstrings and appsettings, then you can split your web.config into seperate files, and have a different file loaded in for each environment. That way, you can check everything into SVN and just update the filename reference in your webconfig depending on which environment you are deploying to.

http://kartones.net/blogs/kartones/archive/2009/09/29/asp-net-split-appsettings-and-connectionstrings-to-separate-files.aspx

Edit: Just seen you're talking about PHP.

Answer 3

In general the best-practice is to store all the custom configuration files under version control. You may want to keep a separate config file for the production and development versions.

If possible, try to extract all the config sections that depend on the deployment environment (connection strings, paths, etc) into separate files. Then link to them from the main (common) config file, so that it will be just a matter of updating the reference when you change your environment from development to production.

Answer 4

I think its best to keep config files in SVN. Regarding settings for staging/production environment, what we do is to have seperate config files for each environment, and then swap them out as part of our build process (using Ant and MSBuild). I.e. we can trigger a "production build", which will copy the production web.config file.

Answer 5

I would have the file in version control, absolutely, as it's generally pivotal to the function of the site. To stop it getting loaded to live, you could look at a build script (e.g. Web Deployment Project), which would switch out your development versions of the configuration with a 'live' version.

---

Sorry, ignore the link, just saw your comment about this being a PHP site - principle is the same however.