James,
I think you may be right that we may not switch to a single DVCS any time soon, but I don't think it's for lack of a clear winner.
The majority of Gnome developers pushing for DVCS seem to favor git (with bazaar at a distant second). Major open source projects (many related to Gnome) have already adopted git (most freedesktop.org projects, X.org, Linux, Ruby on Rails, OLPC), so there's plenty of experience both using git for large projects and migrating from another VCS.
At any rate, I think there are few people who disagree that DVCS of some kind could improve Gnome development (most interestingly, I think, is the possibility for changes that don't fit nicely into a few commits or a single release cycle).
I'm not claiming that I fully understand all sides of the argument (git is the only DVCS I've used), but the only arguments against git that seem valid are cross-platform issues (which seem to be less significant than they used to be) and migration issues (which we would have moving to any new VCS, and as Federico suggested, shouldn't necessarily be that bad).
I wish it were as simple as just providing mirrors or translation services to let developers use any VCS they like, but any translation between VCSes is going to be imperfect. So using x-to-Subversion really isn't ideal - especially when you're going from a DVCS to Subversion, flattening branches and commits and losing original author attribution in the process.
I know I'm not alone in saying that a migration to git would be a major step forward for Gnome and one that few contributors would regret.
Update 1: link to cgit.fd.o, as suggested by Daniel
You're forgetting GNOME experience
A lot of the projects you mentioned are very Linux specific. GNOME is not. Further, there is a strong push for Git, but I don't get why. I understand why Bzr is not good now, but I do know I'd consider it good enough soon. Just an ack or consideration of the problems with a roadmap to fix.
The current treatment of core infrastructure to me is very strange. Especially considering the Beast problem during CVS->SVN, the restart of the whole conversion process. The various problems found during Beast testing, etc.
(bkor)
Re: You're forgetting GNOME experience
There seem to be a few full git conversions of Gnome modules (see the last section) - even GTK+ is in git upstream (I wish I'd realized that in time for the original post).
As other commenters have pointed out, much-improved Windows support has already been migrated to the upstream git.
And we certainly could use more sysadmins on your level. I wish I had a good solution for that :-/
Re: You're forgetting GNOME experience
Re: You're forgetting GNOME experience
There have also been a lot of improvements in Git with handling case-insensitivity recently. The msysgit port also got merged into Git recently, so the next major release will fully support Windows, also without the cygwin environment.
Git and cross-platform issues
So saying that Git works on Windows is almost like saying that Microsoft Office works well under Linux, and point to instructions on how to install and set up VMware Workstation... Yes, it works, but no, most developers are not gonna wanna use it.
It's basically the same issues that you'll face trying to turn any Windows developer on to your favorite open source project, no matter how cool the technology is it's very likely that most will be turned off the second you take them through installing and setting up mingw and using autotools. Yes my dear friend, running 'configure' might take 20 minutes but it's okay, you should just switch to Linux if you get tired of waiting because of fork() implementations not being able to do copy-on-write and spawning thousands of sub-processes a second. And hey, it might fail because the OS sees it as a local DoS attack, but it's fine, just keep running configure my dear friend, config.cache is your friend.
Sorry, but Git's UI needs replacing, shell-scripts simply aren't portable and that makes Git orthogonal to OSes like Windows.
MinGW support
It means that the next version will have it (if all goes well).
just do it
All regrets become invalid immediately.
git clonegit commit
git pull
git push
In other words, there's just a couple new concepts and one new operation in that (the distinction between commit and push in DVCS). GUIs, like Giggle make those operations point-and-click (and Giggle even visualizes the source tree history).
So, it's certainly possible to do fancy things with git, but they certainly aren't requirements.
I don't doubt for a second that git will eventually be choosen for gnome, I hope that at least a balanced study will be made of git's usability problems, and that corrective action will be taken before any switch is made.
Just look at this boggling excerpt from the description section of the git-rm manpage: "Remove files from the working tree and from the index. The files have to be identical to the tip of the branch, and no updates to its contents must have been placed in the staging area (aka index). When --cached is given, the staged content has to match either the tip of the branch or the file on disk."
That's a lot of jargon there, I hope users don't need a CS degree to use git.
USABILITY FAIL! ;)
But I think it's mostly the fact that the git man pages make it look harder than it really is. So it's still a problem, but I don't think it's a fundamental one.
non-technical contributors
A major class of contributors to Gnome are the translators who, as a group, probably are as many as the developers. Most translators are not programmers; they translate in part precisely because that is the way they can contribute - documentation writers are another, smaller group.
SVN is already a pain point for translation, as evidenced both by the frequency it comes up in translation mailing lists and in repository-related problems caused by translation team members. Moving these people over to git would be ..challenging. Be prepared to have lots of nontechnical people do strange things to your repository, and see translation levels drop.
That, or suggest a way non-technical contributors can get around this stumbling block and check out and check in their work without being exposed to a VCS directly.
Re: non-technical contributors
Again, git is not the complicating factor here.
Translators
DVCS
That is sort of what I fear about GIT. Debugging and developing for Linux is non-trivial and has a huge barrier for entry - especially at the embedded Linux side of the spectrum. GIT simply is consistent with the current state of debuggers / development tools - ultimately command line centric w/ many cryptic commands.
I don't see that changing sadly.
Re: DVCS
As far as difficulty debugging and developing in Linux -- what are you referring to?
Difficulty for ISVs to work on a platform with limited ABI stability? That's true for the kernel but Gnome has a great record there?
A lot of that is up to personal taste - I'm sure some non-Unix-centric developers prefer big, feature-heavy IDEs, etc. (not that we don't have a wide selection of them), but I haven't found a lack of decent development tools in Linux.
GIT is great, but not on Windows
I'm not a GNOME developer but I try to contribute somehow.
GIT is a great DVCS for me, I use it in my projects. I've also used bzr and hg but GIT is my most favorite VCS for several reasons.
The only problem is that I encounter troubles when working on Windows. If I've written a file say in UTF-8 under Unix, once I clone the repository under Windows I get the index dirty as soon as some terrible mechanism will convert a couple files to Windows CRLF. It happened sometimes ago so I don't know if it's still happening with later versions. But yes, I agree GIT isn't as portable as others.