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

[Frederik Schwarzer]

On 11/04/2011, Shlomi Fish <shlomif at iglu.org.il> wrote:
> Hi Wolfgang,
>
> see below for my response.
>
> On Monday 11 Apr 2011 09:55:10 Wolfgang Rohdewald wrote:
>> 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.
>
> Yes, but then it has to be kept on disk with the entire history.

And that is considered a plus for many.
For one-repo-per-app it is not that bad either disk-space-wise.


>> 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 discuss the argument that "we should expect processor speed/network
> speed/storage to keep up with our demands" here:
>
> http://en.wikibooks.org/wiki/Optimizing_Code_for_Speed/Factor_Optimizations
>
> (see "The Motivation for Factor Optimizations")
>
> The problem is that checking out everything from a git repository may be
> very
> slow due to either poor bandwidth, or the so-called ISP "traffic-shaping".
> For
> example, my connection should be something like 300 KiloBytes/s , but I'm
> getting a much lower bandwidth from most sites outside Israel, due to my ISP
> being sucky.
>
> Furthermore, git does an all-or-nothing clone - if you interrupt a git
> clone,
> the partial repository is deleted, and you need to restart the clone all
> over
> again. This is while a Subversion working copy checkout (or its svnsync
> command for cloning a repository from remote) *can* be resumed from a
> partial
> state.

Thant's true. Some other KDE modules already switched to Git. KDEEdu
being the recent one. If they see problems, they (or we) will find a
way to fix them. If many people complein about broken downloads, there
might be a weekly snapshot or something.


>> 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
>
> That will add a lot of complexity to the process.

Yes, it will. But the move to git added so much convenience already.
It will just be a different way of doing things. Yes, re-learning. It's annoying
sometimes and Git can be tedious to work with ... but KDE is not a
"let's listen to all of our contributors and do only what everyone
wants" community. The majority seems to see the need for Git and do
the switch was initiated.
The SVN server will go away in the long-term according to the Sysadmins.

It seems to me that something like git-annex will be used at some
point to deal with the binary file issue.


>> 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.
>
> The problem is that the many binary files take a lot of space in the
> history,
> where they are stored as big binary blobs. Cloning a repository with this is
> time-consuming and occupies a lot of space on the disk.

His point was that whether you have 300 MB or 500 MB on your disk,
does not matter much.

The download part does, however. Or at least, I see that problem.


> I don't know git intimately enough (and would rather avoid learning it too
> much because it's so complex, idiosyncratic and counter-intuitive).

I think here you nailed it. You do not like Git ans thus try to find
reasons to argue with. It is way to late for this kind of argument.
These points were all evaluated at least a year ago. The decission was
made, now we have to think about the inevitable issues and bring up
solutions.

I totally see your point though. With Git's increase of complexity,
there is a bumpy road ahead of us for at least the next year. But
getting to know other things with all its ugly sides can be an
adventure as well. :)


> Regarding "I am sure" - "[citation needed]". Splitting the games into a
> different repository per game will add complexity to the process, and will
> make maintenance harder (including branching, tagging, refactoring, etc.)
> and
> developers won't like it.

I would like it. I am in favour of the one-app-per-repo approach.
KDEEdu also split, KDEGraphics split, many apps remain in Extragear
because they do not want to be a module, ...
So it is not even close to "the developers won't like it". True, some
don't. But that's no majority.

> I volunteer to help in maintaining this. And a Subversion service does not
> require a lot of maintenance. In any case, the KDE services are a tool and
> should serve the needs of the users and developers, and we should not go to
> too many extra lengths to twist our workflow so it will match what is a bit
> easier for the admins. Tools are tools, and should not be our master.

That is a pure opinion-based argument. It works the same way against Subversion.

I think there are up- and downsides for all ways to go. The time for
the flavour kind of discussions is over, in my opinion. Now KDE moved
to the "let's find solutions" step and I think that's a good move.
These solutions are worked on on the Kde-scm-interest mailing list
rather than here. I do not think the KDEGames module could make a call
here, even if we would all agree.

Regards