I've been endeavoring to set up a code repository (or even a document repository, if that need should arise) and have been weighing the merits of both Git and
SVN.
At the very heart of the comparisons lies the manner in which Git and
SVN operate.
SVN is a central repository. When you "checkout" a file in
SVN, you get only the most recent version. Should you need to do backwards comparisons you must communicate with the server for this. You get no history, either.
SVN relies on the availability of the central repository to operate.
Git, on the other hand, is fully distributed. There is generally a "blessed repository" from which everyone will start and ultimately commit to, but when you "clone" that repository you get a full copy of it. Backing up a Git repository with many contributors is actually trivial as there are countless copies of that repository floating around.
BranchingAnother major difference revolves around branching. In Git, branching is a way of life (as is the subsequent merging of branches). You want to develop a new feature? Branch on your local box and work on it there, then merge it back into your local main repository before committing back to the blessed repository.
This is not so in
SVN. Branching is not done as often (nor as easily). Branching must occur in the central repository and is not a way of life. In this area Git outshines
SVN.
Client ToolsOne area where Git does not outshine
SVN is in the client tools.
SVN has been around forever (in digital terms). There are very elegant clients for
SVN (such as
TortoiseSVN) which allow for an incredible ease of use when working with repositories. Further, most modern
IDEs have
SVN repository manipulation as a core capability. There are several options for working with
SVN in Eclipse, for instance, one of which is core to Eclipse itself.
Git, on the other hand, is young. The tools out there are not nearly as elegant nor are they as wide-spread. What's worse, Git is incredibly Linux centered. There are two Windows clients for Git (with the advent of
JGit, that will climb to three), all of which require one to work with the command line. Some GUI projects, such as
TortoiseGit, are in the works but will not be ready for prime-time for a while. The last issue here is that there is only limited integration with
IDEs. With time, these situations will change, but for now it is a major draw-back to adoption by those other than the most determined.
Ease of SetupTo the end that I would like to work with both systems I decided to set up both on our Windows Server 2003 server. I chose to use
Cygwin and
OpenSSH, along with
Gitosis (a Perl mod for Git), for Git. I used
Shannon Cornish's tutorial to set things up (along with a little help from
scie.nti.st on matters
Gitosis). This turned out to be a rather easy and relatively painless way to go about things.
The basic gist is that you install Git when you install
Cygwin then install and setup
OpenSSH (by far the most difficult part). At this point you can connect to the server using SSH and clone any repository you would like. Installing
Gitosis on top of things (recursively using Git, no less, which is so cool in my book) allows you to use public/private key pairs to authenticate users. You can then use Git to clone the control repository of
Gitosis and admin the system remotely. Very elegant and one which doesn't require the anticipated user to have to input a password or create an account on the server.
Setting up
SVN was more difficult. The differences, though, are myriad. While the above Git scheme works on SSH the method I chose to use for
SVN works over HTTP/HTTPS, which has advantages all of its own. I worked off of several tutorials, but the most significant was
this tutorial.
The real difficult part here is that you have to rely on Apache. It seems a bit overkill to have to install Apache and get it running in order to serve up your repository, but this is the accepted way of doing things. Once you have it running you must still log into the server to create a
username/password combo for any user that wants to use the system, and you must also log in to the server in order to administer the repository.
The Best of Both WorldsI have to say that the thing which gets me most excited about Git is the notion of branching it carries with it. I really
like the thought of creating a local branch for every new feature. It seems natural to me.
On the other hand, I don't think that I want to saddle everyone else around me with command line tools and vi if they want to work with our repositories. So, can a compromise be made?
In fact, it can! Git has the wonderful ability to clone and commit to
SVN repositories. The real details are outlined
here by Clinton R. Nixon. In this way, I can take the pain of the command line on myself without foisting it on anyone else, but I also get all of the wonderful features Git brings with it.
ConclusionIn light of all of this, we will be hosting our repositories using
SVN. However, I will be keeping an eye towards the maturity of the Git clients. If they should ever advance to the level where any "power user" can attain them, then we very well might switch.