By the way, I've submitted issue #525 at https://polyglot.network/, just in case they know of any demand for fixing it and can help aggregate that demand.
And I've linked to this thread from the issue, so All The Things are connected now at least.
Best regards,
-Karl
[1] https://issues.apache.org/jira/browse/SVN-525
On 25 Apr 2020, Mark Phippard wrote:
>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
Received on 2020-05-12 07:37:57 CEST