subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: Proposal: new fsfs.conf properties
Date Tue, 11 Jul 2017 19:11:58 GMT
On 11.07.2017 15:39, Markus Schaber wrote:
> Hi, Paul,
> From: Paul Hammant [] 
>> 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

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

View raw message