Here are three:

* Sample data for test suites. I have single files of such larger than 21MB in my current project's git repo, and I've seen much bigger. * Audio resources. * Large PDF documentation items.

Photoshop mockup of a page?

On one hand "don't store binaries" on the other, it's a work product for the project, and it makes sense to be stored and versioned.

I suppose, I never really version control those, just track the revisions by uploading updates of the comps for the client, or using share drives if I'm working with other designers. I don't think you can merge PSDs, so many of the benefits of an SCM vanish.

I agree, you lose the merging when you work with binaries (for the most part).

But when I was at HP, our little team was behind the curve in tool use, and I was pushing for a comprehensive scm, instead of the patchwork we had. My big selling point was that given a stack of windows and database install disks, and the scm, you should be able to bootstrap the project up, and get it running.

I really like that point of view when it comes to SCMs. It's the official repository of everything project related. You have code, docs, graphics, everything needed. You do lose out on merging and stuff with binaries, but that's a small price to pay for the peace of mind you get.

Here is a working example of doing diff patches on PSDs.

http://www.codediesel.com/tools/transferring-psd-files-quick...

I've never tried it.

Large SQL scripts, large images/video (I have one web app where the project is 1.3 GB), PSDs, PDFs, web apps that allow you download binaries (installers, software, etc...).

All in all, I'd say that 70% of projects I've worked on have had files in SVN that are bigger than 10 MB.