Software Journal

After my previous post on SVN and CVS, I was pointed in two directions (independently) to Git, and Perforce. The suggest to Git came in form of the Tech talk by Linus Torvalds at Google on source code management. In this talk, Linus blasts CVS, SVN, Perforce, Google and the rest of the software industry.

So, then I got about researching Git. Firstly, its premise is quite faulty – about commit access, etc. Linus spent about 10 minutes solving a problem I don’t have (Reminds me of CueCat!). He says the basic problem is that you don’t want to give commit access to everyone, but then politics comes in, so you end up giving commit access anyway. (And hence distributed source code management, and hence Git.) Hmm, that is really weird – I have never heard of this “commit access politics” problem. I don’t have this problem in my current job at NTELX where I am responsible for managing all software products. Further, I have never had that problem in any of the other software jobs that I have had. Checked with a couple of friends at Microsoft and Facebook (combined the questions with happy holidays phone calls) and those friends do not know of this problem either. So, I am forced to assume that this specific “problem” is a problem only for open source software projects. I don’t think it makes any sense for commercial software companies. We have enough carrots and sticks in place, that perhaps open source software projects don’t. I am personally notified of every single commit that happens to the head, and then, if I have the time and inclination, I may do a source code review. Most of the times though, the commit seems to be in line with what product and module the specific team is working on, and you just let it go.

So, what carrots and sticks does a commercial company have in place? An obvious stick is the employment itself. If you do make a wrong hiring choice and end up giving “commit access” to someone who should never have had it, as soon as you realize that, you take away the commit access and make the right recommendation to HR, take the stuff happens route, and go back to step 0 (recruitment). Carrot is obviously in form of developer appraisals and bonuses. People are usually happen when they get it. (It is nothing like this Dilbert.) There are many other levels between carrots and sticks, which roughly amount to better training and communication. Most usual error that developers make is of trying to develop without forcing that all gaps in the spec be filled, and that can be fixed by telling them exactly that.

All in all, I gave up discounting Git, because I gave up discounting Linus. Half the times I could not be sure whether he was being serious, in which case it would be tremendously arrogant, or if he was being funny, in which case the joke was being pulled on way too long. One way or another, Linus, I don’t know anything about you, but you are no Turing or Tarjan, at least, not yet.

One other point, though played a role in discounting Git. It says that in centralized versioning systems, the central repository is an obvious point of failure. Doesn’t take a genius to figure that out, but it is worth pointing out that since 2000, I have not once had this problem of my central repository going down. Not once. And somehow I am supposed to worry about that? Even if happens right this very day, so what? Our sysadmin will replace the lost disk with the off site backup from 4 hrs ago, developers will recommit the files (that they have on their hard disks anyway), and we will move on. If that is the biggest thing that Git is going to solve for me, then really, it is not that big.

Next, I researched Perforce. I used Perforce a while back at a project, and liked it decently enough. I am still open for using it, and am researching its pricing and cost benefits statement.

Enter Comments

Posted on Saturday, December 26th, 2009 at 8:20 PM in review   |  RSS feed