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

On Sat, Apr 25, 2020 at 2:18 PM Daniel Shahaf <d.s_at_daniel.shahaf.name>
wrote:

> Mark Phippard wrote on Sat, 25 Apr 2020 18:01 +00:00:
> > 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
>
> Does #4 apply to commits, updates, or both?
>

I would say both.

> what is a large binary file that shouldn't be deltified?
>
> is the important question here. The idea is to have reasonable default
> behaviour out of the box, without adding mandatory configuration knobs.

In reference to Brane's question ... I agree doing it automatically would
be better. I would be +1 if someone figured out a good way. It seems like
getting the plumbing in place would be a good first step though. IMO, the
complications are:

1. Not storing the pristine seems at least mildly controversial to do
automatically depending on one's workflow. I could always live with it, but
I almost always work while attached to a network. Perhaps this could just
be a local conf file option that applied to all binary files .. maybe with
a corresponding svn:xxx property that overrides the conf file?
2. Trying to identify a specific subset of binary files that need these
features seems hard. There are past threads of people talking about how
some large binaries do compress well, such as certain types of tar files.

Personally, I suspect binaries that compress well is rare. Maybe if these
features could be implemented we should just flip this around and make
these new behaviors the default for all binary files and require a property
or setting for the exceptions? Anyway, it seems premature to discuss this
in too much depth unless someone thinks writing this code would be
straightforward. I assume it must not be, and as I mentioned earlier,
unfortunately I am not prepared to be able to offer any help.

My sense, with no hard data to back this up, is that the CollabNet
customers I am aware of that are sticking with SVN are doing so because it
already handles large files and large repositories better than git, plus
for some of them it offers locking workflow which is useful for binary
files. I suspect if SVN were to get even stronger in this area it would
cement this as a viable niche where SVN remains the best tool for their
needs.

-- 
Thanks
Mark Phippard