views:

280

answers:

5

What is best practice for using subversion (SVN) for managing a project that requires a single configuration file that has multiple concurrent versions for different environments.

I.e.

  • Project ABC is used for three different environments, that use the same code, except for a slightly modified configuration file. AND
  • Project ABC is also developed by multiple developers, using a slightly modified configuration file for each developer.

I am aware that a configuration file template and svn:ignore could be used, but was wondering if anyone could describe best practice for this approach, and/or any other suitable alternatives.

Thanks in advance!

M.

+3  A: 

I don't know if this is a "best practice" but this is how I handle this and it works very well. I have several apps and they each have a separate config file for their production, staging and dev environments. The configs are named web.config, stage.config and dev.config. All three are kept under version control. The app expects and uses web.config to retrive configuration settings. As part of our NANT build and deployment scripts called by cruise control, depending on the environment being deployed to, the appropriate config is renamed to web.config and deployed.

Hope this helps.

Matt Wrock
I second this. Also, a slight permutation of that method that can be used if there are very few differences between the config files (ie a couple SQL statements and a couple app settings) is to store the changes in the build script, itself and use NAnt's xmlpoke to update to the proper connection string. You can then keep you build scripts in their own repo and keep the production passwords separate from your code base.
Michael La Voie
+1  A: 

Keeping multiple files in source control can be tricky. We use a home brew configuration tool that reads a system environment variable and from that reads a matching config file and then modifies a shared configuration file. I can't say it's a great solution, but it works.

csharptest.net
A: 

Thank you all for the answers. If anyone has any other suggestions, I'd love to hear them. Unless I hear otherwise, I'll probably head down the suggested path of maintaining multiple config files.

Thanks again!

Morgan
A: 

For years, and many different, successful projects, I just don't version the system or developer specific config file. Sometimes it is just database access info, or a few vital paths or whatever. Narrow it down to as little as possible. Don't feel bad about not versioning that info. This has been done with every number between 2 and 5 developers on several projects and it has never caused confusion, problems or debate on real world projects.

Palo Verde
A: 

In my opinion it is no use in keeping all configuartion files under version control. In one of my projects we had configuration files that were created with cmake for several platforms (from the same template). Every dev on our team had its own customized additional script to create the configs needed.

fmuecke
but if you never committed any config file under vesion control, how do you agree on which one is the default one? dont u at least need a default one to be the template?
ShaChris23