For many people in KDE, svn no longer meets their needs for teamwork-based development. The ability to easily merge branches, to work radically off-line and a fairly impressive list covering various benefits of git are often cited as reasons to make the move. Personally I don't think it's a panacea as git comes with its own set of issues, though it is getting better and better every time I upgrade to a new version of it. I think it is quite a bit better than svn is for how we tend to work, though. That hardly matters, though, because our developers are voting with their feet.
Not only are some projects already hosted on gitorious.org, including some big ones like Amarok, a growing number of KDE developers are using git-svn so they can use git for their work and simply sync svn up with their changes periodically. The result is that our world is getting more and more fractured, with some work happening in git repositories and some on svn.kde.org. This is not optimal for the health of our community as there is a real benefit from having each other's code within "close reach" of everyone else's and only having to learn a limited number of tools to work with. When it was just svn being used (and before that cvs), we benefited from a kind of network effect and a lower barrier to entry. We're in danger of eroding both of those things.
So unless we say "no, you can't use git for anything KDE", which seems a bit draconian and probably not only unfair but risky (in terms of losing contributors), we need to get this house in order again.
The bonuses like having a better revision control system and being closer to Qt's mainline development are just bonuses next to that.
What Should Git Be For KDE?
When it comes to the migration itself, I think it is pretty important that we avoid some evident pitfalls.
First, we need good documentation on how to use git so that when the time comes we can all move over and waste as little time retooling as possible. It will help alleviate the apprehension carried by some KDE developers as they being moved to something new, and we all know how much people dislike change. :) This has been started on Techbase and seems to be making really good progress. So, with some more effort (and possibly helpers), that looks like one issue is (being) taken care of.
Next, git must not be allowed to cause "developing in secret bunkers" to start to occur in KDE. Due to its highly decentralized and off-line features, git (and other systems like it) can lead to people working on their own, self-isolated from the group for extended periods of time. This really isn't very healthy, but since it's a social problem it needs a social solution. Just being aware of it and reminding people who seem to be dropping out of the picture for extended periods of time should hopefully be enough.
Git must also not be allowed to make developing for or following development of KDE software harder. A single, canonical mainline must be kept to keep that bar low. We really don't have the need for long lived personal branches that deviate significantly from mainline and which people then have to pick between when getting KDE source code. This seems very common (and for good reasons, in my opinion) in the Linux kernel project, but it isn't a necessity when using git. Git enables a lot of workflows, and I think we should be careful about straying too far afield from the workflows which work for us today. I can't wait for feature branches to be easy to do in Plasma, but I really don't want to see the notmart-plasma and the aseigo-plasma. ;)
Between some good decision making on the part of the people doing the git migration (so we don't, for example, end up with a mess of modules with no clear purpose) and some social engineering we should stand to profit handsomely from the git migration. Seeing how we already have the kde-developers group on Gitorious (so we can all commit to the whole code base once it is in git, just as we can now in svn) and the plans the migration team have put together, I think we'll do fine.
But first we need to do the actual migration...
What Are We Waiting For?
The Move To Git page has a nice list of things that are yet to be done. Some things left are business topics such as KDE e.V. and Gitorious entering into an SLA. Some are technical (such as getting rid of svn externals, of which there are two blockers still there, one of which I'll be getting rid of in the next week or two), some are social. The team meets every week on irc and has been making fine progress.
So we aren't quite there yet, but we're a lot closer than we were a month or two ago. I'm really hoping we can complete the migration before 4.5 is out and do a great job of helping our community move over to the new system. That will allow us to do some git hand holding at Akademy and develop the 4.6 release with some shiny new tools at our disposal. As such, this made my "Key Quests for 2010" list.
(This article is part of the "Key Quests for KDE in 2010" series)