Compression of SVG(Z)s in git repositories

[Milian Wolff]

On Tuesday 02 September 2014 17:00:47 Dominik Haumann wrote:
> 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 ;)

You'd only need to compress it when the file changed. Otherwise incremental 
builds will just install the compressed files in your build folder.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de