Workflow and switching to Git, part 2: The tools

In the first part of this blog, I discussed a bit the change process and the development process we're aiming for.

It's interesting to realise that we're going through the same process both in KDE and Qt. It's also interesting that it's happening at the same time for both -- well, slightly ahead for Qt. That's not, however, a coincidence.

I read a comment on the dot article about opposing a VCS switch every two years. Well, we're not switching just for the fun of switching. We're doing it because there are many compelling reasons to do so. (Also, it's been over 3 years since the Subversion switch, about 4 since we started seriously considering it; Trolltech has been using Perforce for almost 9 years)

And it's happening now because the DVCS tools have matured enough that we can migrate massive repositories into it. The Qt repository right now has about 170,000 commits and is over 900 MB in size (in Git, well packed). And the KDE repositories I imported had 79404, 71892, 60182 commits for kdelibs, kdebase and koffice, respectively.

And because the old processes and tools have become outdated. And, finally, because we're people and we talk :-) (that is, exchange of experience and opinions)

Switching to Git

So far I have not approached the second part of my blog title. There's a very good reason for that: most of what we want to do, the workflow we want to introduce, does not depend on any specific tool. There are feature requirements that many tools do not fulfill, but many do fit the bill.

So why Git, in specific?

We had a lengthy process internally at Trolltech trying to decide whether we should switch to a DVCS and, if so, which tool it should be. That was a very interesting process, but one that would deserve an entire blog on the subject. We had a restricted set at the beginning, but only two serious contenders at the end: Git and Mercurial.

At one point, we came up with a list of what were the criteria we were going to use to make the decision. And then we took a look at which criteria were showstoppers. At the end of the process, there was a clear winner.

The most important criteria in that decision were:

  • Quality of the conversion process (from Perforce)
  • In-house knowledge of the tool
  • Ability of the tool to support our proposed workflow

While the latter criterion was a tie between Mercurial and Git, the first two is where there was a clear winner.

(Disclaimer: there were other reasons, with a varying degree of importance, including some where Git lost to Mercurial)

And if you look at it, those are the exact same criteria that are of importance to KDE now. Sure, there are other tools that also do the job, but who's going to do the conversion? Who's going to support and help the developers who aren't familiar with the tool?

For close to a year now, we've had the kde-scm-interest mailing list, whose mandate is to propose a plan to convert from Subversion to another VCS (or Source Control Management - SCM) and how the layout and workflow would be with this tool. Which VCS, it's not specified. Any is welcome, barring CVS (we're not going back), Subversion (it's not conversion if we stay where we are) and solutions that aren't Free and Open Source.

If you inspect the archives, you'll see that there's only one contender. So far, anyways. Others are more than welcome to join and repeat the process for other tools. But mind you: you're a year behind schedule.

This weekend, I finished converting the KDE Subversion repository into Git. The process created no less than 493 different repositories: I decided that each application in extragear, kdereview, kdesupport or playground should get its own repository. There will be more when I run it again.

The process isn't correct yet. There are definite import errors found: for instance, Thomas Zander inspected the the KOffice repository and realised that several branches were missing. What's more, I still have a few ideas to do copy-with-history, which means preserving correctly the moves in SVN. Many of our projects originated in the old kdenonbeta, which I didn't import.

I am forced to realise that Git isn't completely ready for us yet. I've been using Git for well over a year now and I can see it improving build after build. 1.6.0 is very nice, but not there yet. So I ask the Git developer community: how do we handle 493 separate but related repositories? Mind you, we want to maintain the ability to build them all with very simple commands.

So, while Git is by no means decided for KDE -- well advanced, I'd say -- it is decided for Qt. We have kickstarted the process to completely switch to Git. Very soon now, we'll be in the final leg of that process and will hopefully have some news on it. Our goal is to stop using Perforce for Qt 4.5 by October 1st.

Blog Topics: