* 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.
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.
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.
http://www.codediesel.com/tools/transferring-psd-files-quick...
I've never tried it.
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.
Q. How large of an individual file is Fossil designed to comfortably work with?
A. Under 10 MB.
http://www.mail-archive.com/[email protected]...
So, as you would expect for an SQLite-backed system, it's only useful for source-code-sized files. Look elsewhere for archiving and versioning your data sources unless they're tiny (< 0.007% of a MacBook hard drive).