Wednesday, May 28, 2008

Google Code, Git and Subversion II

There have been a couple of posts on the Google Open Source Blog. The second one is an in depth article about mirroring git repositories to Google Code's (GC) subversion repo. Having tried this out in the past, and helped a blog-commenter through the steps to mirror his git repo in svn, I can't help but feel that the post causes more problems than it solves.

First off, it's way too complicated! I'm quite experienced at using both subversion and git now, but I really cringe at that last set of commands to push to the svn mirror. Compared to "git push origin master" when using a native git repo, it makes me feel queasy. If I were the cynical type, I'd say that Google are just trying to make git look overly complicated compare to svn by forcing git to jump through hoops. Compare the command-fu there to a normal everyday "add, commit" work cycle and no wonder people have a bad impression of git.

Subversion is a lossy repository format. Author information is lost, date information is munged. The svn repo just has the author who ran dcommit, not the guy wrote the patch. Nor will it preserve the correct date, just the time when you ran dcommit. The admin user may change subversion revprops (date, message, author) but that's more manual steps and more opportunity for messing up.

If anything goes wrong while pushing to svn - and it will, the Google svn servers fail every now and again, they're only mechanical - then your push-to-svn git branch gets hosed. Like "git reset git-svn" hosed, so you can just send one big patch. If you have to sync more than a few commits, it's a bit risky. The blog hints at this problem ("commit to a local repo and use svnsync"), but the fact is that it's all a bit slow, sucky and error prone.

However, there's an easier way - cut Subversion out of the loop. On your GC page, go to Administer > Tabs and fill in the Source field. Add a wiki file named Source, for example, and in it place instructions on how to clone your proper git repository from github.com, repo.or.cz, or wherever. Then just use svn for the wiki, GC for the downloads and the issue tracker.

Git works OK on Windows too, apart from some strange CRLF problems. Yes, CRLF problems. In 2008. I know, it's crap.

"Why not widen the audience?" the GOSB asks us. And I ask, why not enlighten the audience as to the benefits of moving on to a next gen VCS? Open up the minds of the Subversion-users, whose patch sets will be both easier for them to create and easier for you to integrate via Git.

Not that anyone ever sends me patches, grumble, grumble...

No comments:

Post a Comment

Note: only a member of this blog may post a comment.