[Kde-games-devel] Move to git now?

[Frederik Schwarzer]

Am Donnerstag, 2. Februar 2012, 02:14:19 schrieb Ian Wadham:

Hi,

> Re the move to git, I cannot see any real benefit in it, neither
> for myself nor for the group, so why do it?

A man here once tried get rid of his garbage can. He did not use it at 
all. He brought his daily oddments diectly to the waste management 
company. Nevertheless the court ruled that he had to pay for his 
garbage can, because it was a community thing and it has to be all or 
noone to keep it maintainable and cost effective.

I see it the same way here. The long-term goal is to get everyone out 
of SVN. Not because SVN is bad, but because it was "decided" once. 
Back then, the goal was to shut down the SVN server. I guess the 
commitee members did not anticipate that the migration would take that 
long.

The current state, while not being ideal, does not kill any effort 
now, afaict. If it would, voices shouting to get the migration over 
with would be louder in that case. But it's becoming a nuisance after 
all.

Long story short: KDE is moving; we are part of KDE.

In case the KDE-wide plan changes and a dual-SCM infrastructure is put 
in place officially, it would be different and we could re-evaluate 
the option of staying in SVN.

However, I would still vote for Git. At first I found Git hard to use 
and found myself in situations where I had to remove the whole repo 
and re-clone it because I could not make sense out of the error 
messages and noone could help me because I was not able to explain how 
I got into that mess. But Git improved quite a bit since then and 
together with me getting more used to it, it sure feels like an 
improvement over SVN in terms of the development process.
To be more explicit:

"git add -p" and "git bisect" are really helpful tools once you get 
the hang of how to use them properly.

I use "git svn" for all my SVN-related KDE work. It is not really a 
"production-ready" workflow. So it is not an option to make it an 
"officially supported" way of working in KDE. Empty folders anyone? :)


> AFAICS, the only reasons given for the change are like "it's the
> latest", "Linus wrote it", "the rest of KDE is doing it", "SVN is
> old hat", etc.  I do not see these as being valid reasons on their
> own.

They are not. Well "the rest of KDE is doing it" actually is valid, 
given that we move as a community. The initial effort might have come 
through one or more of the "invalid" reasons. But that should not be 
something to be discussed at this point.

For me it's really technical. Git has some pretty nice features as 
stated above. :)


> I am very happy with SVN.  It keeps the code safe, has a full audit
> trail, allows a revision to affect more than one file and is easier
> to use than CVS was.

Indeed! I still see projects using CVS and I do not care to contribute 
to them anymore, if it's only minor stuff. I rather send an email to 
their list telling them what I would fix and hope they fix it 
themselves. It's not that I consider CVS so inferior that I do not 
want to touch it anymore. But my todo list is always long and I prefer 
not to use an SCM where I have to read how-tos to use it because noone 
is using it anymore. The same will eventually come for SVN in a few 
years.

I am not sure if comparing cvs->svn with svn->git would be valid. I 
have not used CVS enough for that. But I think that at some point many 
developers will refrain from touching code in SVN like I refrain from 
touching CVS.


> So if we move to git, what will be the benefits for individual
> programmers and for the KDE Games group in making the change? 
> Will the gains in productivity (churning out games code) outweigh
> the effort involved in changing?  How do we know?

We cannot know. I think there are gains in the personal workflow (as 
stated above). But yes, I also see some downsides.
- Global commits are no longer possible (I used them a lot to
  fix common issues a few years ago). So if an issue is found
  in one app, it is not possible anymore so simply just grep
  for the issue globally. I do not see a fix for that.
- Module builds are harder to accomplish. While I see solutions
  for this, I also see that not enough people care enough to
  actually put them in place.
- Dependency hell. I stopped building KDE from source due to
  this. It's ridiculous how some developers split their code.
  Well, it might even make sense from the developer's point of
  view, but they also lose testers. And pointing out that everybody
  could write a script to get module build pretty easily, does not
  solve the problem. Because noone will.
  However, I do not see that problem for kdegames. One repo per
  game seems reasonable. We could probably have a super repo that
  has a CMake file in it which fetches all the games. Additionaly
  we could maintain a kdesrcbuild config snippet in there to build
  all games. This has to stay on our agenda.


> Re the data-files problem, why bother with the history? I see
> on http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git that you
> can select the revisions you want, so why not just archive earlier
> data files on SVN or its branches?  How often do you really need
> that history? Is it a big problem to follow another link to get
> it?

Given that SVN is supposed to go away, that's not an option.
Amarok created two repos. "amarok" and "history".
https://gitorious.org/amarok
The "amarok" history only goes back to 2010 or so.
(gitorious sucks, btw, so I cannot go further back)

I do not think something like that would be needed for the games 
though. If each game has its own repo, then size is no concern (unless 
proven otherwise by the actual trial run, of course).


> One worry about going non-monolithic is how anyone outside KDE
> Games (or inside, for that matter) can get a comprehensive list of
> all available games and can build all games as a block if so
> desired.  And how will people know when there is a new game or a
> major re-write or upgrade of an existing game.  I think we will
> need a "superbuild" at least, but that may not solve all problems.

The mailing list should be used to announce new/gone/rewritten games.

As for the list of all games -> 
http://projects.kde.org/kde_projects.xml
Every "project" under the "kdegames" module would be a game.
No, I do not consider that info easily digestible. Someone would have 
to write a script to extract the needed data. Preferably generic 
enough to be useful to all modules. But well, the irony. ;)


> Also, how will releases, mods to games and mods to libraries be
> co-ordinated?

Dirk does the tagging and release stuff.
For lib changes it works like it works for all projects with external 
dependencies. If the lib changes in a way that makes changes in the 
game necessary, do the changes in the game. It is quite convenient to 
do such changes in one commit in SVN, but it's not that bad to do it 
in two commits either.


> I do not want us to repeat any of the problems that
> arose in the first release of KDE with git repositories, nor any of
> the build problems I encountered early last year in trying to
> build Phonon, KDE libs and all its dependencies after they had
> been ported to git. There were teething problems there.

I would rather compare our approach to move with what happened in 
kdeedu. I am not sure how it went there, but everyone had gathered 
some experience with the steps needed to migrate so I guess it went 
way smoother than the first few modules/apps.

The migration will affect us, like every change does. But a change is 
not what brings things down. It's the way the people cope with it. So 
it is important that we stick together and do not attack each other 
for "being wrong" or "discussing too much" or "being a fanboy" and 
stuff like that. Git is just another tool. Just like SVN, it works. 
Some prefer gas stoves, some prefer electric stoves. But everyone is 
able to prepare a meal on each of those if they just stop arguing and 
start cooking.

That said, I was really happy to see Wolfangs rules arrive yesterday. 
:)

I will write a different mail for that now.

Regards