Go forward in time to July 2008.
The main reason [why git-mirror.gnome.org doesn't make git.gnome.org any easier] is of course the polluted logs (filled with git-svn rev id metadata). I would resist any module having a Git repo with such ickyness in its history.
This is a non-issue. Ruby on Rails used to be hosted on Subversion, and then it switched to Git. To do the conversion, they simply used git-svn. You can do "git clone git://github.com/rails/rails.git", then "git log" and search for "git-svn" in the output in order to find the git-svn metadata.
You'll see this:
... git-based development goes here ... commit 67022671bfa28d5675a30925a8d1e271c576f4d2 Author: David Heinemeier Hansson
Date: Thu Apr 10 22:09:13 2008 -0500 Testing commits commit ed99dda174da439a0947cdabea3babf027c672ac Author: Rick Olson Date: Thu Apr 10 18:06:05 2008 +0000 Change validates_uniqueness_of :case_sensitive option default back to true (from ). Love your database columns, do n't LOWER them. [rick] git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@9248 5ecf4fe2-1ee6-0310-87b1-e25e094e27de ... svn-based development went here ...
So, in the commit logs, you have everything since $beginning_of_time until $switchover_date with the git-svn-id strings, and everything after that without any such garbage, as would be normal for "plain" git repositories.
Having that metadata in the log actually provides valuable information.
If you have to do code archaeology (which Eric Sink calls "traceability"), then the commit log will tell you when the svn->git switchover occured. Before that point, you know that any branches are dead-ends and merges are funny (svn didn't handle them).
You'll know that before the switchover point, information about code attribution will not be 100% clear, as you couldn't specify --author in an svn commit (so you'll perhaps have to look at the actual ChangeLog and hope that the committer was kind enough to say "original patch by $author").
When you do a conversion between revision control systems, you keep the old system around in read-only mode for if anything goes wrong. It's nice to know that if we ever need to check something in the original SVN repository, we'll have the SVN revision numbers from the git-svn metadata.
Finally, the git-svn strings in commit logs will disappear really quickly from your everyday view. They just appear further and furter back in time, and you seldom look at those commits, anyway.
Mario Ðanić has been investigating about adapting Gitorious for KDE. He says he would be happy to talk to people who would like to adapt Gitorious for GNOME's needs as well. Among other things, Mario is working on the Summer of Code to write a GNOME client for the openSUSE build service.
Git-mirror.gnome.org is AWESOME and John Carr deserves large amounts of beer for it. The git-mirror has already saved my ass twice this week ("Where is this patch in trunk? Was it backported to the stable branch?"). Now that we actually have full Git repositories of GNOME, we could easily move to using Git for everything.
Søren, Bryce, James, and myself had a pretty productive time hacking on support for RANDR 1.2 in gnome-desktop, gnome-settings-daemon, and gnome-control-center, all in Git repositories.
Gitorious is like a free version of Github: you can create public Git repositories in a central server, push to them, and monitor who clones your repositories. Later those people can inform you, "I have some cool stuff in my repo; you should fetch those changes from it". Or you can say the same to them, and Gitorious/Github will notify the people in question. This is far, far more productive than monitoring an svn-commits-list or similar.
Gitorious is hosted in a Gitorious installation itself, so you can of course "git clone" is source code. It would be reasonably easy to use this in GNOME's infrastructure, and it would automatically let module maintainers communicate better with contributors (and allow contributors to play with experimental branches without disrupting the maintainer's work).
... Which reminds me, if you are tired of wasting your time with Subversion, be sure to attend the BoF on distributed version control systems at GUADEC, where Behdad and yours truly will delight you with our widely-acclaimed acrobatic act.
Go backward in time to May 2008.Federico Mena-Quintero <firstname.lastname@example.org> Wed 2008/Jun/25 12:37:04 CDT