Compression of SVG(Z)s in git repositories

[Dominik Haumann]

On Tuesday 02 September 2014 12:48:07 Martin Gräßlin wrote:
> On Tuesday 02 September 2014 12:27:11 Sebastian Kügler wrote:
> > On Monday, September 01, 2014 12:59:04 Elias Probst wrote:
> > > I've noticed, that (except of only a very few) nearly all SVG files are
> > > committed as SVGZ to our git repositories.
> > > 
> > > This has IMHO several drawbacks:
> > > - every change will be stored as a single atomic blob
> > > - git's internal packfile compression and deduplication can't be used
> > > - no diffs for changes done to SVGs can be viewed
> > > - batch-editing of files via sed/awk/… is way more difficult
> > > 
> > > I'd like to suggest to implement a git hook which enforces SVG files
> > > being pushed uncompressed.
> > > The compression of SVG to SVGZ might happen when building release
> > > tarballs.
> > > 
> > > What are your thoughts? Any reasons not to do this?
> > 
> > Compressed SVG files are way faster to read (it's faster to decompress the
> > data than to read it from disk). Also, the on-disk footprint is lower.
> > 
> > Both of these affect the runtime performance of Plasma.
> 
> which is not an argument against storing them as SVG in the repository.
> There could be a pre-install task in CMake which compresses them.
> 
> I think Elias suggestion makes sense on the git repository level, we just
> need to first put in place the CMake bits to ensure the installed files are
> still svgz.

I also believe this is the point of Elias.

On the other hand, this looks like us working around a limitation of git. A 
proper solution would be that git itself decompressed the svgz internally 
behind the scenes. I once have heard something like this but can't remember 
right now the details. Anyone else?

If the make install procedure takes longer just because we need to compress 
every icon, then trading size against time is not the best compromise ;)

Greetings,
Dominik