With the recent change over to my Mac, I’ve started to really take a look at the differences between SVN and GIT.  I’m still in the process of learning how to use both bundles for TextMate so when I’m actually in “work mode” I’ll usually forego playing around and just use the command line and I’ve noticed some definite differences.


SVN is actually what I’ve been using the longest, and am much more familiar with.  However using it from the command line is something I’m not very familiar with because up until my switch to my Mac I have always used TortoiseSVN which is probably the best implementation of an SVN client out there because of it’s integration right into the Explorer shell.

Some of the pros of SVN:

  • Output is much more descriptive
  • Without branching it is completely straightforward
  • A lot of documentation out there to help you get started
  • Easier to move between old revisions

And, of course, some of the cons:

  • Slow and clunky feeling
  • Hard to setup initially
  • Pain to fix merge errors
  • Branching is a chore
  • Require an “always on” server/connection

Pros In Depth

Descriptive output

By default, committing, updating, checking out in SVN yeilds very clear and easy to read output.

Macintosh:upillar_motors danahern$ svn up
U    app/models/notifier.rb
U    app/views/notifier/invite_users_private_en.rhtml
U    app/views/notifier/question_for_seller_en.rhtml
U    app/views/notifier/reply_to_buyer_en.rhtml
Updated to revision 5776.

You get a clear understanding of what it is doing every step of the way.  With GIT the updating is a little harder to understand

Macintosh:truth danahern$ git pull
remote: Counting objects: 17, done.
remote: Compressing objects: 100% (10/10), done.
Unpacking objects: 100% (14/14), done.
remote: Total 14 (delta 4), reused 14 (delta 4)
ecd1c5c..73c70a0  master     -> origin/master
Updating ecd1c5c..73c70a0
Fast forward
README.txt |   62 +++++++++++++++++++++++++++——————————–
1 files changed, 28 insertions(+), 34 deletions(-)

Straight forward workflow

As long as you aren’t branching SVN’s workflow is a lot more straight forward than GIT.  You have your server repository which is the definitive copy, then you have your local copy that you work on and then check files into the server repository.

Tons of documentation

Both have been around for a long time, however GIT has only recently really hit the limelight as the new choice for code repositories.  SVN has oodles of documentation out there, and while this won’t be a factor for much longer, GIT is still catching up with regards to documentation explaining the how’s and the why’s.

Moving between revisions

This might be a short coming on my part, but SVN feels a lot easier to move between revisions.  You do a little research to see what revision you want to grab and then just do an update with a “-r <revision number>”.  I haven’t yet gotten the hang of reverting to previous revisions with GIT. Thanks to Pieter, I’ve found out that reverting in GIT is just as easy as SVN (In fact far easier when using Github). git checkout

Cons In Depth

Slow and Clunky

SVN really doesn’t excel at giving me the feeling that it’s actually doing something.  It feels slow, committing a large file or groups of large files leave you sitting at “Transmitting Data.” forever.  No status indication, which means you don’t know if you should sit there and watch, or maybe go grab a bite to eat, enjoy some TV then come back and hope it is done.

Hard to setup initially

I haven’t really ever had to do this by my self, but from the experiences I’ve had with others as the developer waiting patiently to start a project or drop an already alpha product into subversion this seems to be a time consuming and difficult process.  I can’t go into the details on what went wrong each time, but I do know that by the end of the process everyone involved was frustrated and praying that there would be a better solution one day.  It should be noted though that once it’s up, as long as you don’t change anything, it stays up pretty solid.

Pain to fix merge errors

Merge errors are a way of life when working with others on a code repository.  The merge errors in SVN are a pain to fix.  Not only does SVN leave the file name with extra characters with the files diff’d into the file name, but it generates 3 different versions of the file and sticks those in there as well.  In reality, one of those solutions or the other would make more sense as a standalone.

Branching in SVN

Branching in SVN is actually so much of a pain, that rather than creating a branch we’ll either create a new repository or just say “screw it” and make a backup copy of the repo and just start committing.  Once you use git’s branching there is no way you could actually stand to go back to SVN.

Require an always on connection

This hasn’t been a real problem for a while, however, on the occasions where our SVN server goes down or for some reason or another I can’t connect to it all development stops.


Git is the relatively new to me versioning software.  I haven’t checked out any of the GUI based interfaces for it yet (and at a glance it would appear there aren’t many), but the command line version has been treating me right for a while now.

Some of the pros of GIT:

  • Everything is faster than SVN
  • Branching is a breeze
  • Github
  • Merge is amazing

Some of the cons:

  • Hard to understand what is going on
  • Github’s pricing system
  • No really good UI
  • Few web based tools

Pros In Depth

Everything is faster

This might be just a perception, but everything on git seems faster than SVN.  From checkout, to merge, to commit, everything seems to speed along on git.  It could be just that it’s more verbose, you can see it actually working instead of sitting there pondering


My heart actually expands three sizes at the thought of how easy the branching is to handle on git.  So many projects I’ve worked on would benefit greatly from being able to branch off and work on a big revision.  The problem that’s held me back so far is that SVN is such a pain to branch, I look forward to getting to branch a lot more.


Github is a great tool.  I would almost wholeheartedly recommend it, and if you only have a few things you’re working on I do in fact recommend it from the bottom of my heart.  It is amazingly simple to setup, and if you see a public project you’d like to patch it’s actually impossible to mess up checking out, and commit a patch. There are some problems with it, which I’ll expound upon in the con section.


Git is infinitely better at handling merging when compared against SVN.  I’ve actually never had a bad merge issue with git.  It’s also far faster than the SVN merge.  It’s a win all around.

Cons In Depth

Hard to understand

Git’s pro is also a con.  It’s very verbose, it tells you exactly what is going on.  It’s hard to understand what it is doing at every step.  Especially when compared to the simple output of SVN.  (To see an example scroll back up to the SVN Pro)

Github’s pricing schema

No one knows better than I do the value of making a buck off your hard work, and I would be more than happy to pay for such a wonderful service as Github. The problem I have with Github’s pricing schema is the limit on space or projects.  However, the way it is setup is based on public/private repos as well as space, this means that because of the limit on private repositories you can’t post all your private client work.  Powered By Geek contracts out to a LOT of companies, and if we want to host all our repos with them then it would cost us a small fortune.

No good UI tool

As of right now there isn’t a good graphical user interface for interacting with git repositories.  SVN has been main stream for a while longer and has had more time for tools to develop, and between Versions on the Mac and Tortiose on Windows. Right now the Git GUI tools are very basic, and not really useable.

Few web based tools

There aren’t that many web based tools out there for viewing repositories.  The SVN tools are pretty mature and refined, however, the git tools aren’t there yet. From the little I’ve read, the git API tools are still developing.  So I don’t think this is going to be a con for very long.

Final Thoughts

I think for our new projects GIT makes a lot more sense than SVN. Since I’ve been working with git with the command line and have gotten used to it I can’t really imagine moving back to SVN. Git really seems like the better tool, but it needs to mature a little more, I think shortly there will be no real con to using git as opposed to SVN.

2 Comments (+add yours?)

  1. Pieter
    Aug 30, 2008 @ 05:03:41

    Checking out a previous revision is just ‘git checkout ” in git

  2. danahern
    Aug 30, 2008 @ 09:22:12

    Thanks! I was looking at an SVN-GIT crash course document and must have missed it, but now I’ve got it reverting great.

Leave a Reply