[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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
  "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.
Received on 2020-04-24 18:42:34 CEST

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.