Musings on Subversion, SVK and Git

So lately the Subversion log has been quiet, because I’ve been doing a lot of development work in a private (local-only) SVK sandbox. This is great for trying things out but it also means that regular progress updates aren’t instantly available to customers.

So last night I stopped working in the sandbox and imported the results back into the main repository, which means that subsequent changes (starting here) will be visible to the public eye.

This temporary lack of communication bothers me, and the lack of remote backup also bothers me: when the repository is on a remote machine you automatically get some redundancy (remote repository, local SVK mirror, local SVK working copy, or copies); but when you work on a local-only branch your only redundancy comes from your daily backups to DVD-R.

So far I’ve been very impressed with SVK’s branching and merging but I am also worried that it might not be entirely bullet-proof. I haven’t been bitten yet, but I occasionally see reports on the svk-devel mailing list about wedged repositories and merge bugs and that worries me.

Also, it’s quite slow. Git, on the other hand, seems solid as a rock and incredibly fast by all reports. I also couldn’t get SVK installed on Leopard the last time I tried, thus forcing me to go back to the mergeless world of vanilla Subversion; SVK, like many other big Perl applications, sometimes resembles a teetering stack of fragile components with unfathomable interdependencies. Git on the other hand is lightweight, portable C. And now that I have multiple branches for the different versions of Mac OS X, reliability and functionality across Tiger and Leopard, as well as robustness of merging is increasingly important.

So I think the writing is on the wall for SVK. It seems inevitable that I’ll move, sooner or later, to Git. There are still a couple of gaps that would need to be filled in, but 90% of what I need is there. This looks to be a nice tutorial for Subversion users looking to move to Git, especially those who are already familiar with distributed version control thanks to their experience with SVK.