[Kde-games-devel] Rule writing, common data

[Nicolas Alvarez]

Stefan Majewsky wrote:
> 2. Frederik, sometime ago you wrote about how to optimise the size of
> the repos with zero-compressed SVGZ and other black magic. I don't see
> that in the checklist on the wiki page I mentioned. Could you please
> explain there what to do for optimal repo size (and how to check for
> it as a reviewer)?

I wrote a C tool to do the "zero-compression" of gzip files, and a bash 
script to run it on every SVGZ file in the repository, but I didn't publish 
them yet (except in pastebins :P). Parker recently rewrote that C tool in 
Python, and said he will push it to the kde-ruleset repo soon.

In my first tests, there were up to 50% gains, but the repository was small 
to begin with (I don't consider 2MB -> 1MB to be a relevant gain). Before 
using it everywhere, I wanted to wait to see if other repos were large 
enough to make it worth the trouble. But by now, we have KPat as the largest 
repo at 37MB. For a repo like that, messing with SVGZ files *is* useful.

Current repository sizes (after git gc):

484K    kubrick
528K    ksquares
588K    kiriki
596K    kollision
748K    bovo
2.1M    bomber
2.8M    kblocks
4.2M    ksudoku
4.5M    libkmahjongg
5.5M    kapman
6.0M    kajongg
6.1M    knetwalk
7.9M    granatier
8.6M    kigo
9.1M    killbots
23M     ktuberling
31M     kbreakout
37M     kpat

However, as Parker said, writing the rules is the priority now. Other 
projects have happily moved to git with 100MB repos without bothering
with dark magic to shrink it.

> 3. What will happen with common data shared by multiple games? I'm
> talking about the carddecks and the Mahjongg tilesets and backgrounds,
> which are currently in the libkdegames and libkmahjongg directories.
> Should these stay with the libraries, or end up in a separate
> repository? If so, it might be a good idea to move them to
> trunk/kdegames/data/ now to clarify this.

If data is duplicated in multiple games' directories, especially if it's 
large data, I certainly agree with extracting it out into a common dir,
and with doing that *before* the git move.

-- 
Nicolas