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).
* 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.
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.
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.
Q. How large of an individual file is Fossil designed to comfortably work with?
A. Under 10 MB.
http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...
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).