What should NOT be under source control?

Question

It would be nice to have a more or less complete list over what files and/or directories that shouldn\'t (in most cases) be under source control. What do you think should be

Answer 1

The best way I've found to think about it is as follows:

Pretend you've got a brand-new, store-bought computer. You install the OS and updates; you install all your development tools including the source control client; you create an empty directory to be the root of your local sources; you do a "get latest" or whatever your source control system calls it to fetch out clean copies of the release you want to build; you then run the build (fetched from source control), and everything builds.

This thought process tells you why certain files have to be in source control: all of those necessary for the build to work on a clean system. This includes .designer.cs files, the outputs of T4 templates, and any other artifact that the build will not create.

Answer 2

Temp files, config for anything other than global development and sensitive information

Answer 3

Going out on a limb here, but I believe that if you use task lists in Visual Studio, they are kept in the .suo file. This may not be a reason to keep them in source control, but it is a reason to keep a backup somewhere, just in case...

Answer 4

Some other Visual Studio typical files/folders are

*.cachefile 
*.backup 
_UpgradeReport_Files

My tortoise global ignore pattern for example looks like this

bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files

Answer 5

Opinion: everything can be in source control, if you need to, unless it brings significant repository overhead such as frequently changing or large blobs.

3rd party binaries, hard-to-generate (in terms of time) generated files to speed up your deployment process, all are ok.

The main purpose of source control is to match one coherent system state to a revision number. If it would be possible, I'd freeze the entire universe with the code - build tools and the target operating system.

Answer 6

If you have a runtime environment for your code (e.g. dependency libraries, specific compiler versions etc.) do not put the packages into the source control. My approach is brutal, but effective. I commit a makefile, whose role is to downloads (via wget) the stuff, unpack it, and build my runtime environment.