Are there other companies out there using SVN for large-binary-blob storage?
I'm wondering if it might be possible to put together a mini-consortium of companies to fund the completion of Issue #525: https://issues.apache.org/jira/browse/SVN-525 "allow working copies without text-base/" Our company keeps medium-large (say, ~5GB) binary blobs under version control in a dedicated Subversion repository, and it works quite well. Subversion can handle files of that size just fine, and it enables us to do path-based authorization (yay) and partial-tree checkouts. [1] But the presence of text-base files in .svn/pristine/ is a real downer :-). The text-base files are mostly pointless in this case, and they double the client-side disk space usage. There is no useful diff between two revisions of these binary blobs: there's no human-readable diff *and* there's rarely any machine-useable diff either (e.g., for reducing network time when receiving an update or committing a new revision). So the only benefit from the text-base files is to make 'svn revert' faster. We'd be happy to have 'svn revert' re-fetch the file from the repository if it meant we could reduce our storage cost on the client side by half. (Plus you'd only lose local-revert capability on files where you know you don't need it, since presumably the no-text-base behavior would be optional per file and controlled via an 'svn:no-pristine' property or something like that.) Is anyone else in a similar situation? If we join forces, we could probably fund one or more Subversion developers to finally get Issue #525 done. I'd be happy to do the organizing (I'm still reasonably familiar with Subversion development and who does what, though I haven't been an active developer in the project in many years). Please CC me on any replies, as I'm not subscribed to users@. Best regards, -Karl [1] We investigated using Git too, but, though Git good for many things, it is not well-suited for this particular job. The Git Large-File Storage extension (https://git-lfs.github.com/) doesn't address most of our needs either; it's solving a different problem, I guess.
