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

An exception:

4 or 5 different answers have said that generated files should not go under source control. Thats not quite true.

Files generated by specialist tools may belong in source control, especially if particular versions of those tools are necessary.

Examples:

• parsers generated by bison/yacc/antlr,
• autotools files such as configure or Makefile.in, created by autoconf, automake, libtool etc,
• translation or localization files,
• files may be generated by expensive tools, and it might be cheaper to only install them on a few machines.

Basically, if you can't reasonably expect a developer to have the exact version of the exact tool they need, there is a case for putting the generated files in version control.

This exception is discussed by the svn guys in their best practices talk.

Answer 2

Anything that is generated. Binary, bytecode, code/documents generated from XML.

From my commenters, exclude:

• Anything generated by the build, including code documentations (doxygen, javadoc, pydoc, etc.)

But include:

• 3rd party libraries that you don't have the source for OR don't build.

FWIW, at my work for a very large project, we have the following under ClearCase:

• All original code
• Qt source AND built debug/release
• (Terribly outdated) specs

We do not have built modules for our software. A complete binary is distributed every couple weeks with the latest updates.

Answer 3

I would approach the problem a different way; what things should be included in source control? You should only source control those files that:

• ( need revision history OR are created outside of your build but are part of the build, install, or media ) AND
• can't be generated by the build process you control AND
• are common to all users that build the product (no user config)

The list includes things like:

• source files
• make, project, and solution files
• other build tool configuration files (not user related)
• 3rd party libraries
• pre-built files that go on the media like PDFs & documents
• documentation
• images, videos, sounds
• description files like WSDL, XSL

Sometimes a build output can be a build input. For example, an obfuscation rename file may be an output and an input to keep the same renaming scheme. In this case, use the checked-in file as the build input and put the output in a different file. After the build, check out the input file and copy the output file into it and check it in.

The problem with using an exclusion list is that you will never know all the right exclusions and might end up source controlling something that shouldn't be source controlled.

Answer 4

*.bak produced by WinMerge.

Answer 5

Like Corey D has said anything that is generated, specifically anything that is generated by the build process and development environment are good candidates. For instance:

• Binaries and installers
• Bytecode and archives
• Documents generated from XML and code
• Code generated by templates and code generators
• IDE settings files
• Backup files generated by your IDE or editor

Some exceptions to the above could be:

• Images and video
• Third party libraries
• Team specific IDE settings files

Take third party libraries, if you need to ship or your build depends on a third party library it wouldn't be unreasonable to put it under source control, especially if you don't have the source. Also consider some source control systems aren't very efficient at storing binary blobs and you probably will not be able to take advantage of the systems diff tools for those files.

Paul also makes a great comment about generated files and you should check out his answer:

Basically, if you can't reasonably expect a developer to have the exact version of the exact tool they need, there is a case for putting the generated files in version control.

With all that being said ultimately you'll need to consider what you put under source control on a case by case basis. Defining a hard list of what and what not to put under it will only work for some and only probably for so long. And of course the more files you add to source control the longer it will take to update your working copy.

Answer 6

OS specific files, generated by their file browsers such as Thumbs.db and .DS_Store