[Kde-games-devel] Very quiet on kdegames

[Parker Coates]

On Thu, Nov 24, 2011 at 09:44, Stefan Majewsky wrote:
> On Wed, Nov 23, 2011 at 9:30 PM, Christian Krippendorf wrote:
>> 1. Why no git? kdegames still uses svn, but for me - and maybe for other - it
>> will be very cool if git will be used. All my daily work is done with git, so
>> i am more practice with that.
>
> I seem to be about the only one who occasionally tries to push the git move
> forward, but I have too much other occupations. The problem is that we
> have very many data files which are handled badly by git. Search the
> mailing list for the keywords "data files" or "kdegames-data" (e.g. on
> kde.markmail.org) for threads with more info. It would be great if you
> could help in driving the migration forward.

There've actually been some new developments in this area. I've had
KDE git genius Nicolás Alvarez (a.k.a. PovAddict) looking at
optimising the git conversion.

He's found that a lot of that bulk is SVGZ files, which git handles
much, much worse than SVG files because every time they're saved the
compression causes the entire file contents to change, giving git
nothing to diff against. (This is made even worse by the fact that
there were some commits that did nothing except recompress SVGZ and
PNG files without changing their content, meaning that two practically
identical copies of the file have to be saved in every copy of the
repo.)

As an experiment, he tried rewriting the history with null compressed
SVGZ files (valid gzip files, that just happen to have zero
compression) that git can see as text and therefore diff somewhat
effectively. This was able to halve the size of the KPat repository he
was working on from 32MB to 16MB.

Now, this is all work in progress stuff, so no promises, but if
similar results are seen with other games, then we might be able to
get repository sizes down enough to avoid having to split out the
data.

Regardless, going forward I think it makes sense to implement a
no-SVGZ-files-in-the-SCM policy, where artists and developers work
with SVG files that CMake converts to SVGZ files at build or install
time. I'd like to work on setting this up, if only I could find some
time. (My daughter's new sleep strategy is "Wake early. Wake often.")

Parker