<p>Let's say you have a typical web app and with a file configuration.whatever. Every developer working on the project will have one version for their dev boxes, there will be a dev, prod and stage versions. How do you deal with this in source control? Not check in this file at all, check it with different names or do something fancy altogether?</p>

[{'answer_id': 6011, 'author': 'Grant', 'author_id': 30, 'author_profile': 'https://Stackoverflow.com/users/30', 'pm_score': 4, 'selected': False, 'text': "<p>Don't version that file. Version a template or something.</p>\n"}, {'answer_id': 6012, 'author': 'GateKiller', 'author_id': 383, 'author_profile': 'https://Stackoverflow.com/users/383', 'pm_score': 3, 'selected': False, 'text': '<p>Currently I have the "template" config file with an added extension for example:</p>\n\n<pre><code>web.config.rename\n</code></pre>\n\n<p>However, I can see an issue with this method if critical changes have changed.</p>\n'}, {'answer_id': 6016, 'author': 'Tom', 'author_id': 20, 'author_profile': 'https://Stackoverflow.com/users/20', 'pm_score': 2, 'selected': False, 'text': "<p>@Grant is right.</p>\n\n<p>I'm on a team with close to 100 other developers, and our config files are not checked into source control. We have versions of the files in the repository that are pulled with each check out but they don't change.</p>\n\n<p>It's worked out pretty well for us.</p>\n"}, {'answer_id': 6017, 'author': 'yukondude', 'author_id': 726, 'author_profile': 'https://Stackoverflow.com/users/726', 'pm_score': 7, 'selected': True, 'text': "<p>What I've done in the past is to have a default config file which is checked in to source control. Then, each developer has their own override config file which is excluded from source control. The app first loads the default, and then if the override file is present, loads that and uses any settings from the override in preference to the default file.</p>\n\n<p>In general, the smaller the override file the better, but it can always contain more settings for a developer with a very non-standard environment.</p>\n"}, {'answer_id': 6019, 'author': 'EndangeredMassa', 'author_id': 106, 'author_profile': 'https://Stackoverflow.com/users/106', 'pm_score': 1, 'selected': False, 'text': '<p>I version control it, but never push it to the other servers. If the production server requires a change, I make that change directly to the config file.</p>\n\n<p>It may not be pretty, but it works just fine.</p>\n'}, {'answer_id': 6020, 'author': 'Greg Hurlman', 'author_id': 35, 'author_profile': 'https://Stackoverflow.com/users/35', 'pm_score': 2, 'selected': False, 'text': '<p>The checked-in, plain-vanilla version of app/web.config should be generic enough to work on all developer machines, and be kept up to date with any new setting changes, etc.  If you require a specific set of settings for dev/test/production settings, check in separate files with those settings, as GateKiller stated, with some sort of naming convention, though I usually go with "web.prod.config", as not to change the file extension.</p>\n'}, {'answer_id': 6081, 'author': 'Sean Carpenter', 'author_id': 729, 'author_profile': 'https://Stackoverflow.com/users/729', 'pm_score': 2, 'selected': False, 'text': '<p>We use a template config file that is checked in to version control and then a step in our automated build to replace specific entries in the template file with environment-specific settings.  The environment-specific settings are stored in a separate XML file that is also under version control.</p>\n\n<p>We\'re using MSBuild in our automated build, so we use the XmlUpdate task from <a href="http://msbuildtasks.tigris.org/" rel="nofollow noreferrer">MSBuild Community Tasks</a> to update the values.</p>\n'}, {'answer_id': 6086, 'author': 'Brandon Wood', 'author_id': 423, 'author_profile': 'https://Stackoverflow.com/users/423', 'pm_score': 3, 'selected': False, 'text': '<p>My team keeps separate versions of the config files for each environment (web.config.dev, web.config.test, web.config.prod).  Our deployment scripts copy out the correct version, renaming it to web.config.  This way, we have full version control on the config files for each environment, can easily perform a diff, etc.</p>\n'}, {'answer_id': 13490, 'author': 'jeremcc', 'author_id': 1436, 'author_profile': 'https://Stackoverflow.com/users/1436', 'pm_score': 2, 'selected': False, 'text': '<p>For a long time, I have done exactly what bcwood has done. I keep copies of web.dev.config, web.test.config, web.prod.config, etc. under source control, and then my build/deploy system renames them automatically as it deploys to various environments. You get a certain amount of redundancy between the files (especially with all of the asp.net stuff in there), but generally it works really well. You also have to make sure that everyone on the team remembers to update <em>all</em> the files when they make a change.</p>\n\n<p>By the way, I like to keep ".config" at the end as the extension so that file associations do not get broken.</p>\n\n<p>As far as local developer versions of the config file, I always try my best to encourage people to use the same local settings as much as possible so that there is no need to have your own version. It doesn\'t always work for everyone, in which case people usually just replace it locally as needed and go from there. It\'s not too painful or anything.</p>\n'}, {'answer_id': 13509, 'author': 'Ryan', 'author_id': 1545, 'author_profile': 'https://Stackoverflow.com/users/1545', 'pm_score': 0, 'selected': False, 'text': "<p>We just keep the production config file checked in. It's the developer's responsibility to change the file when they pull it out of source safe for staging or development. This has burnt us in the past so I wouldn't suggest it.</p>\n"}, {'answer_id': 36767, 'author': 'Damien Diederen', 'author_id': 3844, 'author_profile': 'https://Stackoverflow.com/users/3844', 'pm_score': 3, 'selected': False, 'text': '<p>+1 on the template approach.</p>\n\n<p>But since this question has tag Git, the distributed alternative\nsprings to mind, in which customizations are kept on a private testing\nbranch:</p>\n\n<pre><code>A---B---C---D---           &lt;- mainline (public)\n     \\       \\\n      B\'------D\'---        &lt;- testing (private)\n</code></pre>\n\n<p>In this scheme, the mainline contains a generic, "template" config\nfile requiring the minimal amount of adjustments to become functional.</p>\n\n<p>Now, developers/testers can tweak the config file to their heart\'s\ncontent, and only commit these changes locally on one a private\ntesting branch (e.g. B\' = B + customizations).  Each time mainline\nadvances, they effortlessly merge it into testing, which results in\nmerge commits such as D\' (= D + merged version of B\'s customizations).</p>\n\n<p>This scheme really shines when the "template" config file is updated:\nthe changes from both sides get merged, and are extremely likely to\nresult into conflicts (or test failures) if they are incompatible!</p>\n'}, {'answer_id': 47015, 'author': 'Rob Oxspring', 'author_id': 1867, 'author_profile': 'https://Stackoverflow.com/users/1867', 'pm_score': 1, 'selected': False, 'text': "<p>On our project we have configuration stored in files with a  prefix then our build system pulls in the appropriate configuration based on the current system's hostname.  This works well for us on a relatively small team, allowing us to apply config changes to other people's files if/when we add a new configuration item.  Obviously this definitely doesn't scale to open source projects with an unbounded number of developers.</p>\n"}, {'answer_id': 50062, 'author': 'Andy Whitfield', 'author_id': 4805, 'author_profile': 'https://Stackoverflow.com/users/4805', 'pm_score': 2, 'selected': False, 'text': '<p>I\'ve used the template before, i.e. web.dev.config, web.prod.config, etc, but now prefer the \'override file\' technique. The web.config file contains the majority of the settings, but an external file contains environment-specific values such as db connections. Good explanation on <a href="http://weblogs.asp.net/pwilson/archive/2003/04/09/5261.aspx" rel="noreferrer">Paul Wilson\'s blog</a>.</p>\n\n<p>I think this reduces the amount to duplication between the config files which can cause pain when adding new values / attributes.</p>\n'}, {'answer_id': 65226, 'author': 'davetron5000', 'author_id': 3029, 'author_profile': 'https://Stackoverflow.com/users/3029', 'pm_score': 5, 'selected': False, 'text': "<p>Configuration <em>is</em> code, and you should version it.  We base our configuration files on usernames; in both UNIX/Mac and Windows you can access the user's login name, and as long as these are unique to the project, you are fine.  You can even override this in the environment, but you <strong>should</strong> version control everything.</p>\n\n<p>This also allows you to examine others' configurations, which can help diagnose build and platform issues.</p>\n"}, {'answer_id': 75633, 'author': 'Jason Stevenson', 'author_id': 13368, 'author_profile': 'https://Stackoverflow.com/users/13368', 'pm_score': 3, 'selected': False, 'text': '<p>The solution we use is to have only the single configuration file (web.config/app.config), but we add a special section to the file that contains settings for all environments.</p>\n\n<p>There is a <strong>LOCAL, DEV, QA, PRODUCTION</strong> sections each containing the configuration keys relevant to that environment in our config file(s).</p>\n\n<p>What make this all work is an assembly named <strong>xxx.Environment</strong> which is referenced in all of our applications (winforms and webforms) which tells the application which environment it is operating on.</p>\n\n<p>The xxx.Environment assembly reads a single line of information from the <strong>machine.config</strong> of the given machine which tells it that it is on DEV, QA, etc.  This entry is present on all of our workstations and servers.</p>\n\n<p>Hope this helps.</p>\n'}, {'answer_id': 1593339, 'author': 'Ian Ringrose', 'author_id': 57159, 'author_profile': 'https://Stackoverflow.com/users/57159', 'pm_score': 1, 'selected': False, 'text': '<p>We have two problems here.</p>\n\n<ul>\n<li><p>Firstly we have to control the configuration file that is shipped with the software.  </p>\n\n<p>It is all two easy for a developer to check in an unwanted to change to the master config file, if they are using the same file in the devolvement environment. </p>\n\n<p>On the other side, if you have a separate configuration file that is included by the installer, it is very easy to forget to add a new setting to it, or to let the comments in it get out of sync with the comments in the devolvement configuring file.</p></li>\n<li><p>Then we have the problem that developers have to keep there copy of the configuration file up-to-date as other developers add new configuration settings.  However some settings like database connection strings are different for each developer.</p></li>\n<li><p>There is a 3rd problem the question/answers do not cover.  <em>How do you merge in the changes a customer have make to your configuration file when you install a new version of your software?</em></p></li>\n</ul>\n\n<blockquote>\n  <p>I have yet to see a good solutions\n  that works well in all cases, however\n  I have seen some <em>partial solutions</em>\n  (that can be combined in different\n  combinations as needed) that reduces\n  the problem a lot.</p>\n</blockquote>\n\n<ul>\n<li><p>Firstly reduce the number of configuration items you have in your main configuration file.</p>\n\n<p>If you don’t have a need to let your customers change your mappings, use Fluent NHibernate (or otherwise) to move the configuration into code.</p>\n\n<p>Likewise for depency injection  setup.</p></li>\n<li><p>Split up the configuration file when possible, e.g. use a separate file to configure what Log4Net logs.</p></li>\n<li><p>Don’t repeat items between lots of  configuration files,  e.g. if you have 4 web applications that are all installed on the same machine, have a overall configuration file that the web.config file in each application points to.  </p>\n\n<p>(Use a relative path by default, so it is rare to have to change the web.config file)</p></li>\n<li><p>Process the development configuration file to get the shipping configuration file.  </p>\n\n<p>The could be done by have default values in the Xml comments that are then set in the configuration file when a build is done.  Or having sections that are deleted as part of the process of creating the installer.</p></li>\n<li><p>Instead of just having one database connection strings, have one per developers.   </p>\n\n<p>E.g  first look for “database_ianr”  (where ianr is my username or machine name) in the  configuration file at run time, if it is not found, then look for “database”  </p>\n\n<p>Have a 2nd level "e.g. -oracle or -sqlserver" make it quicker for developers to get to both database systems.</p>\n\n<p>This can of course also be done for any other configuration value.</p>\n\n<p>Then all values that end in “_userName” can be striped out before shipping the configuration file.</p></li>\n</ul>\n\n<blockquote>\n  <p>However in the end what is you is a\n  “owner of configuration file” that\n  takes the responsibly of managing the\n  configuration file(s) as above or\n  otherwise.   He/She should also do a\n  diff on the customer facings\n  configuration file before each\n  shipment.</p>\n</blockquote>\n\n<p><strong>You can’t remove the need for a caring person some this short of problem.</strong></p>\n'}, {'answer_id': 5905724, 'author': 'JackAce', 'author_id': 738985, 'author_profile': 'https://Stackoverflow.com/users/738985', 'pm_score': 3, 'selected': False, 'text': "<p>I have always kept all versions of the config files in source control, in the same folder as the web.config file.</p>\n\n<p>For example</p>\n\n<pre><code>web.config\nweb.qa.config\nweb.staging.config\nweb.production.config\n</code></pre>\n\n<p>I prefer this naming convention (as opposed to web.config.production or production.web.config) because</p>\n\n<ul>\n<li>It keeps the files together when you sort by file name</li>\n<li>It keeps the files together when you sort by file extension</li>\n<li>If the file accidentally gets pushed to production, you won't be able to see the contents over http because IIS will prevent *.config files from being served</li>\n</ul>\n\n<p>The default config file should be configured such that you can run the application locally on your own machine.</p>\n\n<p>Most importantly, these files should be almost 100% identical in every aspect, even formatting.  You shouldn't use tabs in one version and spaces in another for indenting.  You should be able to run a diff tool against the files to see exactly what is different between them.  I prefer to use WinMerge for diffing the files.</p>\n\n<p>When your build process creates the binaries, there should be a task that overwrites the web.config with the config file appropriate for that environment.  If the files are zipped up, then the non relevant files should be deleted from that build.</p>\n"}, {'answer_id': 21111088, 'author': 'Benny Emmers', 'author_id': 3190261, 'author_profile': 'https://Stackoverflow.com/users/3190261', 'pm_score': 0, 'selected': False, 'text': '<p>I faced that same problem and I found a solution for it. I first added all the files to the central repository (also the developer ones).</p>\n\n<p>So if a developer fetches the files from the repository the developer config is also there. When changing made to this file, Git should not be aware of these changes. That way changes cannot be pushed/committed to the repository but stay locally.</p>\n\n<p>I solved this by using the git command: <code>update-index --assume-unchanged</code>. I made a bat file that is executed in the prebuild of the projects that are containing a file whose changes should be ignore by Git. Here is the code I put in the bat file:</p>\n\n<pre><code>IF NOT EXIST %2%\\.git GOTO NOGIT\nset fileName=%1\nset fileName=%fileName:\\=/%\nfor /f "useback tokens=*" %%a in (\'%fileName%\') do set fileName=%%~a\nset "gitUpdate=git update-index --assume-unchanged"\nset parameter= "%gitUpdate% %fileName%"\necho %parameter% as parameter for git\n"C:\\Program Files (x86)\\Git\\bin\\sh.exe" --login -i -c %parameter%\necho Make FIleBehaveLikeUnchangedForGit Done.\nGOTO END\n:NOGIT\necho no git here.\necho %2%\n:END\n</code></pre>\n\n<p>In my prebuild I would made a call to the bat file, for example:</p>\n\n<pre><code>call "$(ProjectDir)\\..\\..\\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"\n</code></pre>\n\n<p>I found on SO a bat file that copies the correct config file to the web.config/app.config. I also call this bat file in the prebuild. The code for this bat file is:</p>\n\n<pre><code>@echo off\necho Comparing two files: %1 with %2\nif not exist %1 goto File1NotFound\nif not exist %2 goto File2NotFound\nfc %1 %2 \nif %ERRORLEVEL%==0 GOTO NoCopy\necho Files are not the same.  Copying %1 over %2\ncopy %1 %2 /y &amp; goto END\n:NoCopy\necho Files are the same.  Did nothing\ngoto END\n:File1NotFound\necho %1 not found.\ngoto END\n:File2NotFound\ncopy %1 %2 /y\ngoto END\n:END\necho Done.\n</code></pre>\n\n<p>In my prebuild I would made a call to the bat file, for example:</p>\n\n<pre><code>call "$(ProjectDir)\\..\\..\\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config\n</code></pre>\n'}, {'answer_id': 35206904, 'author': 'gafi', 'author_id': 3716153, 'author_profile': 'https://Stackoverflow.com/users/3716153', 'pm_score': 1, 'selected': False, 'text': "<p>I don't think there's a single solution that works for all cases as it may depend on the sensitivity of data in the config files, or the programming language you're using, and so many other factors. But I think it's important to keep the config files for all environments under source control, so you can always know when it was changed and by whom, and more importantly, be able to recover it if things go wrong. And they will.</p>\n<p>So here's how I do it. This is for NodeJS projects usually but I think it works for other frameworks and languages as well.</p>\n<p>What I do is create a <code>configs</code> directory at the root of the project, and under that directory keep multiple files for all environments (and some times separate files for each developer's environment as well) which are all tracked in source control. And there is the actual file that the code uses named <code>config</code> at the root of the project. This is the only file that is not tracked. So it looks like this</p>\n<pre><code>root\n|\n|- config (not tracked)\n|\n|- configs/ (all tracked)\n    |- development\n    |- staging\n    |- live\n    |- James\n</code></pre>\n<p>When someone checks out the project he copies the config file he wants to use in the untracked <code>config</code> file and he is free to edit it as he wishes but is also responsible to copy these changes before he commits to the other environment files as needed.</p>\n<p>And on servers, the untracked file can simply be a copy (or reference) of the tracked file corresponding to that environment. In JS you can simply have 1 line to require that file.</p>\n<p>This flow may be a little complicated at first but it has great advantages:</p>\n<ol>\n<li>You never have to worry about a config file getting deleted or modified on the server without having a backup</li>\n<li>The same if a developer has some custom config on his machine and his machine stops working for any reason</li>\n<li>Before any deployment you can diff the config files for <code>development</code> and <code>staging</code> for example and see if there's anything missing or broken.</li>\n</ol>\n"}]
['https://Stackoverflow.com/questions/6009', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/556/']