I have a few files of a .NET app that are different in the production server from the development server. For example:
- Web.config
- MasterPage.master
- account/account.aspx
- blog/Web.config
- and a few more...
What is the best way to manage these differences with SVN? I've heard everything from maintaining a config folder in the trunk to creating a branch with the "different" files, then merging them into the release tag.
I use SVN trunk for main development (stable) and tag the trunk when it's ready to be released. The trunk deploys to my development server and the release tag deploys to the production server via FTP.
One possibility is to leave this up to your build/deploy process.
So, for Web.config you would have the following in SVN:
Web.config (this can be your development version)
Web.config.qa (if you have a qa environment)
Web.config.prod
At build/deploy time, your deployment process "knows" what environment it is deploying to (based on however you control this - environment variables, script parameters, etc), and substitutes the correct config file in its place.
I prefer this method because it leaves your directory and file structure intact (vs. having a config folder), as well as avoiding unnecessary branches and merging pains. It does require diligence in ensuring that all the files are updated when changes are made that aren't environment specific, but you are going to pay this price regardless of strategy.
Visual Studio 2010 added Web.config transformations and in 2012 they added the ability to perform transformations on all configuration files. In this way the correct configuration files are generated when you do a publish to a given environment. Here is some information regarding the built-in options: http://msdn.microsoft.com/en-us/library/dd465326.aspx
You can also use the excellent SlowCheetah XML transforms extension here: http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5
In the end you'll have Web.config.dev, Web.config.prod, tranform files which are automatically run during Deployments, they can all be kept under version control with no need to branch, merge, diff, etc.
