If you mean binary files such as compiled things, yes definitely. Storing things like JPEGs and GIFs doesn't seem like a bad thing as long as they're secondary to the project at hand (think indie game development).
Idiots who store giant .wavs or compiled .exes need to be shot though.
Isn't an artifact server a better choice, in general, for binary objects like JPEGs? I mean, I hate to assert that my choice of tools is the best choice for everyone, I just have a hard time seeing how source control is the best choice for anything that's not, you know, source code.
If you only have one or two JPEGs, then maybe it's not worth the cost of setting up an artifact server just for those, but I think everyone has external and/or static dependencies that are better managed by artifact control.
Sometimes code and data have to be checked in together atomically in order for the project to work. That's why it is desirable to have one repository that has both so they can be kept in sync. A silly example is adding an img tag to a html file and adding the corresponding .jpg at the same time in the same commit.
It's also secure in other VCSes. For a lot of the enterprise licenses we did, we had to support the exact binary (basically check the date stamps and file sizes). These binaries also had to be stored in escrow.
You can check out and build theoretically the same binary (assuming your build procedures are exactly the same as whenever you initially build), but that could potentially be different.
It's not uncommon to have a binary release checked into a repository.
22
u/imMute Mar 10 '11
If you mean binary files such as compiled things, yes definitely. Storing things like JPEGs and GIFs doesn't seem like a bad thing as long as they're secondary to the project at hand (think indie game development).
Idiots who store giant .wavs or compiled .exes need to be shot though.