Re: Who else is using SVN for large-binary-asset storage?

On 25 Apr 2020, Mark Phippard wrote:
>On Sat, Apr 25, 2020 at 1:54 PM Johan Corveleyn <jcorvel_at_gmail.com>
>wrote:
>
>While hand-waving on all of the details, it seems like if we had some
>property one could put on a file that combined all of these concepts
>we could have a really compelling solution for handling large
>binaries.

(At a certain point this discussion should start happening on dev@, probably.)

Obviously, the UI by which one accesses this proposed new feature is separate from how the feature is implemented under the hood.

Given that keeping or not keeping text bases is a purely client-side concern, properties shouldn't be the only UI gateway to this feature. It's even more important to offer client-side *configuration* to be able to say things like:

* Files larger than size X don't keep a text base

* Files of mime-type BLAH don't keep a text base

* Files with at least one property from [some set of arbitrary properties] don't keep a text base

* ...etc.

The key thing is that the client decides, since this is purely a client-side decision about trading off between local storage cost and network turnarounds for diff and revert.

>I am not sure Karl's use case but I know video game
>companies have raised the issue in the past, and I know some of our
>customers deal with things like large binary files for embedded chip
>designs etc.

The use case I have in mind is exactly that one: checking out files that are both large and non-mergeable anyway (luckily, these two things tend to go together).

>But the final goal should be something like this (in order of
>importance):
>
>1. Do not store a pristine in working copy for the file
>2. Do not do deltification on the client when committing
>3. Do not do compression on server when storing
>4. Do not do deltification on server

If (1), then (2) is implied (unless by "deltification" you just mean "compression without reference to any pristine text base").

(3) and (4) are a separate project IMHO. They're interesting ideas & worth pursuing, but they have no effect on client side storage and are thus outside the scope of what I was proposing FWIW.

Best regards,
-Karl
Received on 2020-05-06 21:41:24 CEST