It's a while since I last used SubVerion with EpiServer. So I'm trying to figure out which files I need to check in with Subversion.
I know I only need to check in files which will change in the project. So this is normally tempalte files. But I do not want to check in files like web.config as this may be different from user to user / computer to computer.
What about .sln and .csproj files?
The .csproj file should definitly be there imho. For the .sln file there are different practises, I personal add it to make it as easy as possible for new developers to get the project up and running (they should just be able to download, build and go). For the web.config file I have a resources folder with the different web.config files placed in it (for local development, test server, staging, production etc). For the app settings I've started creating an appsettings.config file which I link to in my web.config file (which is under source control). I also have a library and reference folder for external projects and 3rd party dlls.
Hope this helps.
.sln and .csproj files should defenitely be checked in. What we do in our project (several developers working on the same files), is that we have a web.config.local, log4net.config.local, etc and we use BeyondCompare to find changes in these files when there are changes in the config files.
You should not add config files or compiled dlls to subversion. And having a separate reference folder with external references etc is also good practice.
That's my point of view :)
As a true believer of the benefits from having all developers work the same way I would recommend also sticking the .config files in the svn repo. if you are many devs working on the same project from time to time this would be especially important.
The problem with this is that you would need some automatic merging of these files into one "master" .config when you check them in. People tend to forget to merge changes that might affect the other developers local environment. Lets say developer A commits some code that has a dependency on som appSettings from the web.config… Developer B updates his code and then his environment is broken… The most common reason developers have different config files is that have their own preferences for where to locate the VPP folders amongst other things. It might be possible to split such configurations into separate config files using the configSource attribute (like you would do with the connectionsstrings element). However if you have a company standard on the locations of the VPP’s, log directories etc. this might be a simpler solution.
I agree with Lars Flågan. Commit your config files and strive to keep them developer independent. I rather force developers to check out to the same drive and location (to keep directory structures the same on all machines).
If you have to change web.config for a period of time, and don't want to commit it by accident, put it into the "ignore-on-commit" changelist in TortoiseSVN which will make it unchecked by default in the list of changed files during commits.
Lars, I have seen the technique you describe fail in big projects with many developers. Committing config files is not just for small and simple projects. I agree that committing config files fits best in smaller projects though.
The most important thing is to find something that works (and I believe committing config files does work) and then adjust as the needs dictate.
One technique I have been thinking about (if web.config is not committed) is to have an xsd file for important settings (those that needs to be defined and have no sensible default values). If developer A adds a setting that all developers should have in their config files, it is added to the xsd file and committed. When developer B updates and builds, a pre-build event is run that sees the missing setting in web.config. The build is then broken until the setting is added.
The same xsd file can be used on test and production servers to verify that the web.config files have the neccessary settings defined.
When considering which files to check in to the repository you need to think about why you are using a versioning system... Most commonly you use it because you want to be able to roll back to a previous version of a file because something is wrong with the current version. My opinion is that this also applies to config files