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

What you can do is have a default config file that stays unchanged, unless some new config is added. Then you have a different file that overrides the default file's configs.

config.Default.xml
config.User.xml

Only config.Default.xml is source controlled. config.User.xml contains only the configurations that are different for you. So, say you are testing on a local SQL server, you put only the connection string in there and it will override the config.Default connection string.

Take a look at .Net Framwork Application Configuration, it does most (if not all) of the work for you.

Answer 2

We have

• *.(config | xml)
• *.(config | xml).cert
• *.(config | xml).production

Hudson deletes the initial file and deploys the correct file for the correct environment (currently only cert).

This allows developers to document and develop production, cert and development level config files independently and have them versioned separately in SVN.