Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 636 posts at DZone. You can read more from them at their website. View Full User Profile

Why I'm leaving Subversion for Git

03.05.2010
| 35635 views |
  • submit to reddit
I always believed in Subversion's potential and that it would be a wide improvement over the nightmare that was CVS, but I found out that, as Linus says, There is no way to do CVS right.
Subversion is fairly good and it's probably the better centralized version control system on the market, and it's open source. But after my first day of Git real-world usage, I now cannot negate that the distributed model of Git will be superior at last.

For example, in Git, you are not forced to have a remote repository: you can start with your local repository, and commit to it. No need to set up server software if you don't want to, as your machine is already your own server.
After working locally for some time and having done very fast commits as you usually did much more slowly with your remote Subversion server, you can push or pull changesets to other repositories. I was worried about the inherent uncertainty in this process (which branch? Which repository?), but Git tracks the origin of your repository, precisely the common ancestor in the remote branch, which your master branch was forked from. When you start by cloning a remote repository (as it is almost always the case), it will push to that origin. But you can also push to nearly everything, even if there is not a common ancestor.
The converse is true: you can also pull to update your repository from an external one, that may be your point of convergence. Obviously, you can also pull from everywhere, in a local branch if you are not sure to incorporate the changes.

The commit access notion vanishes in Git. You and I typically do not have commit access to major projects such as Zend Framework or Doctrine anyway (ok, I have to Doctrine, but when I come out with a small patch I just put it the bug tracker for a review), and we have only our working copy, having to upload patches to the bug tracker. Multiple versions of those patches. That quickly become not in sync with the current revision of the codebase.
Collaboration between working copies is difficult, as an official branch is needed. Moreover, it's rare that you know a branch is needed ahead of time. If for every feature you started a remote branch, even with Subversion (which has cheap copy-on-write branches) the development would be very slow. So many times you end up working on the trunk and struggling because you cannot break it, and sending patches by email. These problems are described in Linus's talk at Google about Git - which is amusing. When I watched his talk using Subversion really started bugging me; I knew that here was an alternative, and it consisted of mature software since the talk was old, from 2007.
What's the solution then? In Git everyone has his own repository, so you can just pull changes from other people and pushing changes to them. There is no commit access, only a group the lead developer trusts and he will pull from. This group may pull and review from other people, in a hierarchical work flow where a chain of trust is established. For an open source project, Git is worth its weight in gold (which actually I don't know, but it will be surely expressed in hexadecimal.)
You can break your repository if you want, committing all the day without problems, and being able to revert to every commit's revision as if Git were a time machine, and very cheaply (in Subversion you are forced to hit the network to revert to revisions older than the last commit.) When you have fixed your copy after ten, twenty or an hundred commits and all tests are passing, you may finally push. Awesome.

And this was only my first day in Git!
References
Published at DZone with permission of Giorgio Sironi, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jilles Van Gurp replied on Fri, 2010/03/05 - 3:19pm

I decided last Saturday to be a Git fan boy in a svn environment. I won't claim it was an easy ride, because frankly it isn't but in the end it delivered as advertised. But I'm better off now and I did get some value out in a week of using git on the job.

My start was saturday morning when for the nth time I was reading about some geek jumping on the git band wagon and totally loving it. I found myself drooling over some blogs and git documentation, again, thinking like this would totally work for me. Then, I thought what the hell, lets try this.

So I read some more to prepare, toyed around with some foobar directories and files and then did a git init, followed by a git svn clone of the svn repository at work. Mistake #1. Our svn repository is huge and the clone took two hours. Worse, I fucked up at some point and had to start all over again. The right way to do things, it turns out, is git svn init -s of trunk/.. (and not just trunk) followed by a git fetch. Anyway, after it was done I fucked up again. So, I had to sit through the procedure again. Then I got smart and rsynced the .git directory to a safe place before doing anything else.

Lesson #1: git gives you version management but not backups. You can and will fuck up and be in need of a backup. You no longer have a server to rely on. You can commt all you like but it won't mean a thing until you dcommit/push to a safe place.

Then, Monday morning at work I was all into git and feeling confident. Wrong! Turns out that most of the svn vocabulary means something completely different in git. I made lots of mistakes. If you feel compelled to do a svn revert -R, probably you want to be doing something like a reset --hard, even though there is a git revert command as well. But it might be that what you needed was a git checkout instead. The semantics of what you may think you know are simply not what you think they are. 

Lesson #2: asume nothing and RTFM before you go anywhere near work stuff. I lost a few hours here. Practice on something you have backups of or don't care about.

Then I hit the ideal uscase for git. One guy in our team had been working on a major refactoring for the better part of two weeks in his local svn work directory and was about to go on a vacation before he could finish things. I was the lucky guy he was transferring it to. So we did a patch and it failed on my git repository. Patches from a windows svn directory to a git directory on mac is just a bit hairy. So instead we zipped up his svn work dir and I deep copied his stuff into my git repo. It just worked. Then I started fixing stuff, occasionally doing a git svn rebase to catch up with svn trunk. I got more confident and did a few renames, including some top level directories.

It just works. Git svn rebase just keeps on doing the right things. Impressive. I'd have been in deep trouble with regular svn.

Lesson #3: git will help you where you are used to being on your own with svn. This is what you are doing it for.

Today (Friday) I prepared myself to push back changes back to svn trunk. I was a little nervous on this one because minus a couple of irrelevant changes this was my first big git commit and I just couldn't afford to fuck this up. Imagine this, I renamed five of our maven modules that people had been committing to throughout the week, integrated some pretty massive refactoring from another guy and I was about to commit this to trunk, days before we are supposed to release. Test passed, stuff compiled and ran fine in our soapui tests. It was ready. All I needed was Git to work as advertised.

Well to make a long story short, I learned a lot about rebasing, how to roll back & fix botched merges, on my sixth attempt I was successful and managed to get my topic branch merged back to the master. Then after hitting enter on the dcommit I realized I should have folded my many git commits back into one big git commit. Too late, who cares. But it is something to keep in mind.

Anyway, all done and behind me. I learned a lot about git this week. Getting your hands dirty is always the best way to pick up something new. Git is not for the faint of heart. If you are not comfortable on a command line, adapt or don't bother. Forget about egit or other git UIs. Totally useless and counter productive. 

Gregory Strockbine replied on Fri, 2010/03/05 - 5:29pm

I started a job when they were looking for a version control system for a new project. Luckily they had no money to spend on it so we wouldn't get stuck with Microsoft Team whatever. So it had to be open source. Previously at this company they had used Rational something or other. Basically we started with a clean slate.

At my previous job we used CVS for about 20 years. I had wanted to try either Bazaar, Git or Mercurial. I picked Mercurial because TortoiseHg is excellent and our development environment was on winXP.

Turns out this was exactly, beautifully perfect for us, because we worked in two locations: had an office computer and a lab a short 5 minute walk away. Only two workstations in the lab.

Here's our setup:

  • central server: main repo on an Ubuntu server
  • office: local repo with Mercurial web server running
  • lab:clone repo from office machine. Can push back to office or to main repo.

Everyone loves Mercurial here at my company. It works and it is easy. I'm not sure about the argument I read about that Subversion is easier to use. I use Mercurial all the time for my home projects too. What can be easier to setting up a repo then : hg init.

Oh yeah, I forgot, this article is about Git. Well Git and Mercurial are similar in many ways and along with Bazaar they all seem to share concepts.

Ben Tilford replied on Fri, 2010/03/05 - 10:37pm

You should check the svn roadmap for 1.7 ;)

Sura Sos replied on Sun, 2010/03/07 - 9:45am

I use subversion at work. It has better tooling support, and easy to maintain. Haven't experienced any problem with subversion that neccesitate us to move to git. I sometimes use git when I am working with new project and I want some local versioning (without adding my project to the svn repository) or with github projects. I move the git project to subversion when I am done with the experiment.

Drew Repasky replied on Sun, 2010/03/07 - 10:39pm

"But after my first day of Git real-world usage, I now cannot negate that the distributed model of Git will be superior at last."

I guess that qualifies you as an expert, and to make predictions.

On an unrelated subject, I just watched my first basketball game and declare it's far superior to football.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.