All of my code nowadays lives in one of two places – my company’s private SVN repo, or on Github (awesome site and service, btw, but that’s for another post).  It wasn’t always this way; recently a friend of mine convinced me to make the jump onto git.  I was reluctant at first, just because I thought I was ‘in the groove,’ so to speak, with SVN.  But, after about 3 weeks of primarily using git, I have to agree with my friend when he says he can never go back to SVN.

But what about all that existing code in my SVN repo?  Git has me covered with SVN bindings – git-svn – sweet! Unlike other apps that attempt to support legacy systems through half-assed functionality, my personal opinion is that git-svn is a better SVN client that svn.

Git-SVN is a better SVN client

Huh?  Well here’s how I think of it – git+svn is to SVN as TCP is to UDP.  TCP makes it simple to ensure that communication packets between a client and a server are complete and in the order that they were sent – an important foundation for something like the internet, where there is massive concurrence, congestion, and instability.  Take this quote from the wikipedia page on TCP and see if it sounds similar to working with your SVN repo:

Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost or delivered out of order. TCP detects these problems, requests retransmission of lost packets, rearranges out-of-order packets, and even helps minimize network congestion to reduce the occurrence of the other problems.

Replace packets with commits and TCP with git in that statement , and you have a pretty good feel for git+svn as a client.  Sure, conflict resolution is possible in SVN, but it sucks.  Git-svn makes conflict resolution dead simple with git-svn dcommit (commit your git repo revisions to svn, while simultaneously updating your working copy), and git-svn rebase (fetch changes to the SVN repo, rewind your repo to apply changes, and then apply your edits on top).  For a full list, check out the git-svn manual.

Actually, git-svn = TCP+UDP

The analogy isn’t perfect (in git’s favor) – as generally TCP is slower tha UDP, and TCP is only meant for 2-end communication.  But from my experience git+svn is much faster than svn, and since your working copy is really just a git repo – you can take advantage of the distributed qualities of git.  So really, the analogy should be: git-svn is like TCP and UDP combined!

Anyways, don’t take my word for it – go try out git yourself!  The fact that you have an entire ecosystem built around your SVN repo is no excuse anymore.