Should my builds be committed?

This is for a web based project where my serverside application code and client side JS/HJTML is under version control. Lets say I release version 1.0, and create a new branch from the trunk with the 1.0 release. I run my build tool which spits out all of the compressed 开发者_开发问答and combined files. Within my directory structure it generates a build directory with the compressed/built files.

Should I commit the build directory so I have a copy of each build/release without having to re-build it if I need another copy (for another server say..)?

Though this is sort of a subjective answer, it is uncommon, I believe, to store build binaries in your version control system. That's really the purpose of tags.

At the time of your release, you should rather be creating a tag of the complete code state including build scripts, tagged with the current version number. At any time a copy of an earlier build is needed, it's a simple matter of checking out the tagged version and building it. The tag holds all information and code state required to exactly duplicate the build at that stage.

If you wish to save the builds somewhere else, that's another matter and is really up to you. Most typically though they do not belong in version control.

Keeping build output under version control is often a good idea. It allows the output to be stored in a structure that mirrors the input. This makes it clear which input produced which output. It also allows easy access to any version's output without rebuilding.

The reasons dismiss it as an option are mainly repository related. Reasons include such things as the repository is too small, access is too slow, or there is just a dislike of having output files in the repository.

But generally, there is nothing inherently bad about doing it. And in many situations it is valuable.

I'm going to say "no", source control is not the place for compilation output. Source control is for managing, well, source - the intention is to store, version and provide collaboration facilities for code.

Ideally, the right place for builds is a build server. This usually means you're not just capturing the compilation output (assuming you save the artefacts post-build), you're also capturing important information such as the build parameters, something you don't implicitly get by just versioning the build output (unless your build scripts are in there too).

Take a look at number 8 in The 10 commandments of good source control management. Of course this is a bit subjective (as some of the comments illustrate), but personally, I don't version compilation output. Perhaps the question you need to ask is "why" you want to version it and what you miss by not doing so.