Do you put non-code files, such as DLL, images, and flv, into version control?

Question

Well, relatively speaking they don't change often, but a positive side of it is that you can check out a website and expect it to run and look normal on your local machine.

What do you do?

Answer 1

Yes. We regularly put external dependencies and anything else required for the build under source contro. This way we ensure that a clean machine can enlist in the sources and build from sctratch, without having somebody manually install stuff on it.

Answer 2

Generally yes. You should be able to grab a project from source control and build it, with no further intervention, on a clean machine disconnected from the rest of your build environment.

For files that rarely change, or for binary files in general, your source control provider might provide some options, like "Store entire file per revision" - this setting prevents the source control program from trying to calculate diffs when you check in a new vision (which is appropriate for ASCII files, just not for binaries).

On the other hand, if there is a network drive or something like that which will ALWAYS be available to all machines building your project, you can get away with referencing that remote resource (be it a true drive or even a URL to an image) as long as you make sure you feel comfortable with the backup process on that remote system.

Source control provides two important features: source sharing between developers, and source backup - a lot of people forget about the second one until it's too late :) Myself included once before. Learnt my lesson! Haha.

Answer 3

I put all "original materials" into version control, including images, external jars/libraries, and other data files that are used as inputs or resources.

I do not put any generated artifacts into version control. That is, anything generated by the build is considered "ignored" or "private" -- not under source control.

Generally speaking, I feel that another developer should be able to check out the project and perform a one-click (or one-command) build to generate a working instance of the product. After doing so, the developer's view should not contain any deltas with the version-controlled source.

I.e. the build should be able to complete on a "locked" version of the code without the need for performing any checkouts, etc. and also without needing to acquire any additional external dependencies (generally speaking).

Answer 4

Yes, we even put the tools we use to build the product in source control.

One sync and you have everything on your box needed to build the product. If you don't, you'll introduce some non-determinism - dev's who don't manually update non-checked in dependencies will waste time tracking down misconfiguration issues on their test machines.

Answer 5

Yes, we do.

You should be able to get the project from source control and have everything needed to build without jumping through hoops.

There's nothing worse than wasting time trying to find dependencies to build successfully. :(

Answer 6

Yes, mostly.

The only files I leave out of source control is the site 'content' which mainly covers images and documents uploaded by the website users. Images that make up the 'look' of the site (usually on the master pages, or loaded via CSS) that are non-editable go into source control.

DLLs and other items required to compile the site (or required for site functionality, such as javascript) are definitely included. Developers should be able to check out a website from source control and have everything they need for a working site.

Answer 7

There is also the argument for putting database dumps into version/source control.

Especially if the schema of the database is evolving during development. (I know, that is another topic entirely)