[Kde-games-devel] Re: A Thought About The Version Control System

[Wolfgang Rohdewald]

On Montag 11 April 2011, Shlomi Fish wrote:
> there was some discussion here about whether and how kdegames
> should  transition from Subversion to Git, including a
> discussion whether to keep everything in a single repository
> or to split each games into a different repository. The
> reason for the entire discussion is because due to the large
> history and many binary files in the svn repository, the
> resultant git repository will be extremely large.
> 
> What I suggest considering is keep the repository as a
> Subversion one and  working with it remotely using Git,
> Mercurial, Bzr or whatever, possibly while starting from a
> later snapshot. The reason is that distributed version
> control (DVCS) is not very suitable for games (though it is
> much more apparent in large-scale commercial games than for
> the KDE games package):

I am glad you re-started the discussion, it seems to have
fallen asleep somehow.

But I disagree with you - very much so.

Please define "extremely large" - how large is that? And
how much does it matter? The full repository has to be
downloaded only once. Updates do not mind how big the
repository is.

Processors, download speed and storage get faster
and cheaper by the day - so in 2 or 3 years people might
find this discussion rather amusing in hindsight. And git
also moves on - look at the git mailing list. Better
support for binary files is very much discussed there
and the git development rate is still very fast.

I am using git svn locally for kajongg. Yes, this is better
than pure svn but many advantages of git are not usable over
those bridges - especially when it comes to branching and
merging.

binary files could be put into separate repositories - 
either one per game or one for all. That should be decided
by the individual game developers. There are already data
packages like kdegames-mahjongg-data - this could be one
repository. Kajongg has some audio files but that is 
currently not much data - if and when that gets too much
we can still start a separate repository kdegames-kajongg-data

I also claim - without proof - that binary files are not
changed as often as source files. So I do not believe they
are a real problem. And if it later turns out that they are,
they can still be split out to binary file repositories. Yes,
that means rewriting history (git filter-branch) and yes, 
that means all developers have to rebase their local work
because all git commits change. But honestly - kdegames
development is really not very active, only a few developers
will notice at all.

I forgot to mention that I am all for splitting kdegames
into a repository per game. Otherwise splitting out binaries
at a later point might be more problematic. I am sure mechanims
will develop for automatically resolving dependencies between
repositories so the argument that this makes it too difficult
for newcomers to git into KDE development is not that strong.

and of course nobody from the outside (of the games developer
community) will understand and accept it if kdegames stays
with svn. The entire infrastructure of all KDE parts
(except i18n for now) is moving to git - AFAIK. If kdegames
stays with svn, a lot of the infrastructure has to be
maintained twice. Guess who will maintain the svn part - nobody!

-- 
Wolfgang