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

Re: Proposal: new fsfs.conf properties

From: Branko Čibej <brane_at_apache.org>
Date: Tue, 11 Jul 2017 21:11:58 +0200

On 11.07.2017 15:39, Markus Schaber wrote:
> Hi, Paul,
>
>
> From: Paul Hammant [mailto:paul_at_hammant.org]
>
>> Markus - I've read your section on deltification and I can see evidence in what you wrote that you're concurrently in favor of and against it (the file-suffix exclusion idea). Can you re-read and clarify?
>>> I agree partly. Skipping compression for known "incompressible" formats like mpX, png or gif can come with performance benefits, saving some CPU cycles (see the recent performance disccussions on this list)
>>> However, I'm not sure whether the same amounts for deltification. There are editing tasks which do not reencode the whole image / movie, and they can profit from deltification, for example:
>>> - Lossless rotation / cropping of jpeg images.
>>> - Editing / stripping the EXIF data of jpeg images.
>>> - Embedding / dropping the preview thumbnail of jpeg images.
>>> - Lossless MP3 editing (e. G. via mp3DirectCut).
>>> - Editing MP3 meta data (e. G. Song Title)
>>> (... and more...)
>>> In all those cases, skipping deltification can drastically increase storage.
> To summarize it up:
>
> I expect significant benefits in some use cases by skipping the compression, thus I'm +1 if benchmarks prove it's worth the effort.
>
> I see the danger of drastically increased bandwith and storage size (transferring/storing the whole mp3 instead of just some changed meta data bytes) in some common use cases when deltification is skipped. Thus, I'm skeptical (count it as -0), and I'd kindly suggest to do some benchmarks for those cases before implementation, and clear documentation of the possible negative effects if it's implemented.

So, first of all, if this is server-side configuration, it has _no_
effect on the client so the client will continue to send (compressed)
deltas. This will have exactly zero effect on bandwidth or client CPU
utilization.

Another issue I have with the proposal is the idea to use file suffixes.
That's usually the wrong way to go about things (case in point: Windows
does it, with didastrous results). It's much better to determine file
format by inspection, such as, e.g., libmagic does. We already have
optional support for libmagic in the client (to set svn:mime-type).

-- Brane
Received on 2017-07-11 21:12:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.