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

The accepted answer is good. However, it is possible to do what you wanted to (4 years ago), and maintain just a single config file which checks out and never checks in -- if your version control system has the concept of changelists. I have done this in Perforce:

Check out the config file and keep it in its own changelist. When you commit, commit only the other changelists; this is easy to remember if you name your config file changelist something like "DO NOT COMMIT".

An advantage of this system is that if someone else changes the production version of the config file -- i.e. the one which exists on the server, and which everyone is maintaining a modified local version of -- then you will be notified of possible conflicts when you get the config file from the server. With a solution like that suggested in the accepted answer, you might keep silently overriding the new production settings with your local settings, which could break your local build or cause you to break the build when you next commit.