Who else is using SVN for large-binary-asset storage?
From: Karl Fogel <kfogel_at_opentechstrategies.com>
Date: Fri, 24 Apr 2020 11:39:50 -0500
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
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,
[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.
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.