Why do we have a shared source code repository for KDE development?
That is not a rhetorical question. :) Perhaps even stop reading at this point for a moment to think about it a bit.
For me the reasons for having a shared source code repository are many. Some are historical (back in the day, pretty well everyone self-hosted due to lack of credible options elsewhere) and some are convenience related (I always have a place to start a KDE related project without much effort thanks to svn.kde.org). These reasons are not particularly compelling to me because they are either not benefit related or are easily fulfilled via other options out there, particularly as project hosting options such as gitorious.org have gotten as good as they have.
There are other reasons, however, that have everything to do with the source code being close together that can not be so easily replaced in my opinion.
There is, first and foremost, the joint issues of barrier to entry and transferability of knowledge. It is amazing that if I want to hack on a given application or library that is produced by the "central" KDE community, there is exactly one place I need to look to, there is exactly one workflow I need to figure out and there is exactly one set of tools I need to learn (cmake, svn; maybe bugs.kde.org and reviewboard). Even our APIs tend towards, quite purposefully, similar idioms for the same reasons: it makes it easier to get up to speed with them.
What we learn in one KDE experience, we can apply again immediately to another. Even as we lower the barrier to first entry to KDE, there has historically been a near-zero barrier to entering a second, third, fourth, etc. KDE project.
It also means that when I want to fix or improve something, as I did with katepart for the 4.5 series, I could dive in immediately. That was the difference between me accepting a poorer solution, working around the problems and actually reaching out to fix it. Admittedly it wasn't a huge contribution, but for the use of katepart in plasma-desktop it was pretty important and it was, after all, a contribution.
We are able to coordinate things like release management much more easily as well: there is exactly one place to look for the official sources, one place to deal with tagging and other administrivia. We have entire workflows built around being able to land code in playground, move it to kdereview for feedback from any interested party and then into trunk proper. We catch more localization issues this way than probably any other single mechanism. These workflows, in turn, are documented on Techbase for people to read, learn and use as guides to getting involved.
There is also the issue of simple visibility: when something lands in a shared space like svn.kde.org many more people notice than when it lands in gitorious.org. For those who watch the commit lists, or when it was alive the commit digest, the ongoing development of a project really keeps it in our sights. It also helps us notice when it isn't being developed so actively. Visibility is a medium of passive communication.
Without a common set of tools, including a revision control system, all of the above is eroded. We begin to lose the things that allow us to easily behave as a coordinated community when it comes to creating software.
Why this question now?
The reason I ask the above question at this point in time is that KDE developers are voting with their feet and moving to git, one project at a time. Moving to a revision control system that gives us better tools is not a bad thing. Quite the opposite, in fact. We also should not try and shut our eyes to the fact that git is becoming, slowly and surely, the new consensus (which does not mean unanimous :) choice for KDE developers. What is interesting about this trend is that it is happening piecemeal: one project here move, one project there moves.
Fortunately, most projects are moving to gitorious.org where we have a kdedevelopers group that can be added to a project to allow some measure of group involvement again. It is inescapable, however, that our community is slowly dividing into two pieces when it comes to where our source code lives, like two continents moving apart on separate tectonic plates. (What's really unfortunate is that some projects have moved to completely different revision control systems that throws them right to the fringes of our community in terms of cross-project activity.)
Let me open about this: I'd like to see plasma hosted in a git repository. There are, however, no benefits to that which trump being close to the rest of the KDE community's efforts.
For those moving to gitorious.org, there are other risks involved. While gitorious.org would be great for a few reasons (proximity to qt, large pool of people who already have accounts there) there are also drawbacks to it. We are currently in friendly discussions with the company behind gitorious.org to have those drawbacks addressed. Part of that solution involves arriving at a financially acceptable agreement for commitments to availability, hosting and ensuring we have access to certain bits of information we must have in case of disaster (e.g. a back-up of user accounts so KDE sys admins could quickly set up a replacement server should something unforeseen happen to gitorious.org). Given that revision control is so central to what KDE does, these are not issues to be taken lightly.
They are, also, not issues that have been resolved yet. I had a conference call during Tokamak 4 with gitorious.org staff and KDE e.V. board members to discuss these issues, so progress is being made towards a decision, but right now it's not a foregone conclusion that KDE will move to gitorious.org. We may well end up hosting a gitorious installation on our own servers.
Having projects jump onto gitorious.org prematurely may end up being more of a hassle than they expect as a result. It is very easy to move a local git repository from one place to another, but then we have to communicate that to all of our contributors and project followers and figure out what to do with things like pending merge requests.
I also see some projects moving to git as a way to work around build system issues: Kate is moving to gitorious because they want to make it easier to build katepart, kwrite and kate outside of kdelibs and kdebase (kdesdk is already simple: just cd into the kate dir and build). That is a huge (and unnecessary) workaround. cmake already supports builds starting from different levels in the host module; that's how we currently manage kdebase as one build vs kdebase-runtime/-apps/-workspace as three separate builds. Working around such issues fixes the problem for some but not for others while causing rifts in our collaboration community.
This is just one more set of reasons to not rush headlong into things just yet.
What are the alternatives?
The alternative is quite obvious in my mind: take the time to coordinate.
There is a git migration project that is making progress week by week. The project is documented on Techbase and can use more hands. It can also use our support, e.g. those two projects who still have svn externals in key places that we can't just ignore (Oxygen and kget) really need to get moving on that (or face more dire results like finding the code migrated one day in a poor state, e.g. with code being copied around or files commented out of the build).
svn.kde.org is not so horrible that we can't live with it for another release cycle. We obviously don't want to live with it indefinitely, however, so a final move-by date must be established, in my opinion, to give all of us something to work with, to ensure all of us that it will indeed be happening within a reasonable time frame. Deadlines rarely hurt. :)
Instead of moving projects one at a time in an uncoordinated, maldocumented mess, let's rally together to coordinate on the move to a new revision control system (which will be git, by popular acclaim) so it gets done well, right and without losing the benefits we've so carefully gathered to this point.