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

Mon Apr 11 13:02:48 CEST 2011

On Monday 11 Apr 2011 12:09:07 Frederik Schwarzer wrote:
> 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.
> 

Well, it is not an advantage if you are short on disk space, which was my 
entire argument.

> >> 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_Optimizatio
> > ns
> > 
> > (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.

Well, how many people is "many"? And if not enough people complain, what will 
the minority do?

> 
> >> 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.

I see. We can host an SVN service somewhere else.

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

OK. I'm not familiar with git-annex.

> >> 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.

Well, your hard-disk gets filled up one megabyte at a time. Although for most 
people, it doesn't matter too much.

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

Yes.

> > 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.
> 

1. You should work on your spelling - "way to late" and "decission" are both 
wrong. 

2. It is true that I find git to be sub-par, but I can tolerate working with 
it. But that's not why I recommended against it for kdegames. I like Mercurial 
much better than git, but still don't think it's suitable for kdegames. 

> 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. :)
> 

OK.

> > 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.

OK, fine. I find maintaining code in two-dozen-of-a-different-repositories to 
be a big mess, and many people will agree with me.

> 
> > 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.
> 

So we are slaves to our tools and the administrators' whims?

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Interview with Ben Collins-Sussman - http://shlom.in/sussman

"We're not doing it for money… we're doing it for a shitload of money!"
    -- Spaceballs, http://www.imdb.com/title/tt0094012/

Please reply to list if it's a mailing list post - http://shlom.in/reply .