SVN vs GIT - why change?

Here at work we use SVN extensively for all our Flex, .Net, Java and other projects. Always on the lookout for the next best thing I decided to take a look at GIT, the supposed SVN-killer.

SVN is great. Sure it has its shortfalls but in the 3 or so years we've been running it we've never once had a problem. Compare to CVS or the dreaded Microsoft SourceSafe with its random and frequent corruption issues, and my life with SVN is good.

Firstly let me talk a bit about our particular use of SVN. We have two repositories. One contains some very old code to be used mainly as a read only archive, the other contains all our current projects. We rarely have multiple developers working on a single project, so for the most part we commit our changes directly to HEAD. We then use Hudson to build various projects triggered on the SVN commit. We rarely use branches, and sometimes tag release builds. Developers use TortoiseSVN or Subversive/Subclipse for Eclipse-based projects.

With GIT, there are some fundamental differences with our workflow:

You clone an entire repository complete with version history to your local machine

You effectively have an entire copy of the repository locally. Whilst this is fantastic for going through file versions, branches etc, it means the initial clone operation can be lengthy. Additionally you're going to be using up much more disk space.

You can't check out/clone just part of a repository

With our SVN usage, we work on parts of our SVN repository at a time. For example I'll checkout repo/client/project1 and work on that. With GIT I would have to checkout/clone the entire repository (which in our case is huge).

GIT works well with one repository per project. There are pros and cons here - you could easily move individual projects around, but managing 100+ repositories will be a headache. Plus there's no way to search across repos, so you'll need to keep a list of all your repos, and know which repo your project is in.

GIT enforces branch/merge workflow

As mentioned above, 99.9% of the time we commit directly to HEAD as there's no reason to go through the branch/merge routine when only one dev is working on a project. Whilst this isn't a best practice, it definitely saves time and avoids any merge issues.

With GIT, you can only work on your local repository which in effect is a new branch, so you have no choice but to perform a merge (called a PUSH) whenever you want your changes to be published to the shared repository.

Summary

I can see that GIT is great for projects that have many developers working on different aspects (it was created by Linus Torvalds afterall for use with the Linux Kernel source repo). But for small shops such as ours the time and effort required to convert would cause us more effort than staying with SVN.