I would like to add some points regarding Lennart's last post on Version Control Systems (sorry for such a long post, but I wanted to make my point here ;-)
First, I completely agree on Lennart's first point that DVCS is not the solution to all of our pains and it won't make people suddenly write better code.
However, I strongly disagree that our decision should be done following a popularity contest, the decision should be taking thinking in the long term impacts of it, not just about the current situation. Okay, the Linux kernel choose git, X.org and consequently fd.o too, but we shouldn't give for granted that if it's a good decision for them it's a good decision for us.
We target to a quite different developer base than kernel.org an freedesktop.org, our project works differently, our culture is different. We sometimes forget that VCS is one of the key entry points for new contributors, the harder it is to learn the VCS, the harder it is to contribute to our project (actually, I would say that DVCS are harder to learn than SVN).
Git is probably the responsible of the current popularity of DVCS, specially after Linus talk at Google, but despite having the best performance and probably being the most popular has its drawbacks as well, and we might consider the impact of those drawbacks on our particular community.
First drawback is usability, at this point git is extremely hard to understand because of its inconsistent and weird semantics and the lack of proper error reporting that denies users to be able to instinctively learn what needs to be done to solve the problem plus current documentation is extremely poor. Now imagine the frustration of new contributors while learning how to create a new project or contribute for their first time to GNOME. I don't think asking people who are already used to one DVCS to learn another one is a big deal compared to force new users, that might not even used a centralized VCS ever, to go through that pain.
Second one is the lack of a portable and reusable design, git is too tied to a UNIX environment, for it to work on Windows it requires msys, curl, perl and other UNIX specific bits this makes really hard to maintain a high quality port of the tool, and ties a Windows user to a bash terminal to effectively use the tool.
Of course we all love the flexibility that a shell based implementation allows by using pipes and that stuff, and that's fine for kernel developers or X.org developers because its source code is aimed to Linux/OpenSolaris/BSD developers in the 99% of the case.
However we have projects at gnome.org svn that are supported on Windows, such as Gtk+ or Evolution. Setting up a development environment on Windows for a GNOME project is hard enough at the moment, using a tool that won't work natively on this platform by design won't make the situation any better in my opinion and this will prevent new contributions from other platforms happening.
On the other side, this design prevents the effective reuse of git from other tools such as IDEs or web services without accessing the command line, which drives to security issues and less maintainable code.
