Should the web.config file be kept updated in a VCS?

Should developers keep the web.config file updated and commit it to a VCS such as SVN? At my company we very rarely update it via SVN; instead somebody will create an "instructions" text file in our deployment scripts (SQL scripts and the like, plus batch files to compile the ASPX files as individual DLLs for deployment) that says something like "Change X to Y in web.config files for Sites A, B and D", and relies on the individual developer following those instructions each time the file is updated.

This seems counter-intuitive to me: I would expect the web.config file to be kept in sync as needed, with necessary changes being made and the file committed as any other artifact of the codebase, but I have raised this issue in the past and nobody has paid it any mind.

What approach should be followed when deal开发者_运维百科ing with config files like this?

---

Absolutely, web config must be in source control, and you can define differences beetween various versions of web.config with web.config configurations

for example we have one for local development server, one for test IIS server, and one for production IIS server. And we can set solution configuration and publish from visual studio for different targets and different clients (sites).

here are the links for web.config configurations :

Common Web.Config transformations with Visual Studio 2010

Web.config Transformation Syntax for Web Application Project Deployment

---

I wouldn't allow all developers to have access to web.config file at all either via SVN or other way. Although if in your company it is allowed for developers to access web.config i see no reason why it shouldn't be on SVN. Point of SVN is to keep track of your single/multi person development process. If you make changes to web.config and this cause a bug in someone's else code it would be much easier to revert changes using SVN