I strongly believe in revision control. Back in the days when there wasn’t any other choice that CVS I spent countless hours setting up CVS servers and re-freshing my mind on its obscure commands and arguments, which were almost all of them. If you drop my copy of Professional Linux Programming it’ll open on the CVS chapter by itself (much like my copy of The C Programming Language will open itself on the pointers chapter, somewhere on the pointers to pointers section).

Then came Subversion and it was somewhat better. After that we got the explosion of revision control systems with the introduction of distributed ones. We’ve got Darcs, Git, Mercurial, Arch, Bazaar, etc. My choice right now is Git. It used to be Darcs, but unfortunately it stagnated for a long time and I moved on to the next new thing. I’ve used Mercurial as well. From my perspective Mercurial and Git are almost equivalent.

For me distributed revision control was a breakthru. There’s one small feature that makes a huge difference for me. In the old days I used to set up CVS or Subversion servers/repositories (in those, a repository is essentially a server-side thing). I had to decide where that repository was going to reside, how it was going to be named, how it was going to be accessed (ssh, http, custom protocol?), by whom, etc.

Today with Git I just do this

git init

That’s it. I’m done. The directory where I am is now a repository. I can start committing, branching, rolling back, looking at the history, generating patches, stashing, etc. It’s that simple. The fact that it’s so simple goes from a quantitative advantage to a qualitative advantage. What I mean is that I not only revision-control things faster but that I revision-control things I wouldn’t have otherwise. For example the configuration directories on my servers.

I know many people will complain: “But with no centralized repository chaos will ensue”. The fact that it’s distributed doesn’t mean there can’t be a central repository. When I want to collaborate with someone using Git I create one repo somewhere, in my servers or GitHub and we both push and pull from there. The difference is that I commit a lot locally, and when the chances are ready I push them. That means that I can commit broken code, without worrying.

At work we don’t use a distributed revision control system, we use a centralized one and we have a very string peer reviewing policy. My current tasks involve touching code in many different files in many different systems never getting familiar to any of them. That means that it’s common for my peer reviews to say things like “all this methods don’t belong here, these two should go there, that one should be broken into three different ones going here, there and somewhere else”.

Now I have a problem. I can’t commit because my peers don’t consider my code ready. My code works but it has to be refactored in a very destructive way. What happens if during the refactoring it stops working. For example copying and pasting I loose a piece of code. I can’t roll back to my working state and start over. If we were using a distributed revision control system I could.

So, being able to commit non-finished code locally while colaborating with other people is one of my other crucial features in DVCS.

The third one is being able to branch locally. In a similar vein as the last example. When I find myself thinking about a very destructive refactoring that I’m not sure if it’s going to get me anywhere and worst than that is going to take me three days to do; I just create a local branch. I experiment in that branch. If at any time I get tired or I need to do anything else I go back to the main one. That is what branching is about.

Why is locally branching better than globally or centralized branching? Well, one reason is that a local branch doesn’t have to make sense to anyone else. I don’t have to pick a name that’s descriptive for anyone else than me. I don’t have to justify myself for creating a branch with anyone else. Let’s suppose I had an argument with a co-worker where I believe something is doable and (s)he believes is not. Do I want him/her to see that I created a branch to prove him/her wrong? I don’t. And if I prove myself wrong I want to quietly delete that branch and never ever talk about it.

But I am starting to go into the very hypothetical realm. In short, for me, DVCS is about this:

git init

and get to code.

Leave a Reply

You may also like:

If you want to work with me or hire me? Contact me

You can follow me or connect with me:

Or get new content delivered directly to your inbox.

Join 5,043 other subscribers

I wrote a book:

Stack of copies of How to Hire and Manage Remote Teams

How to Hire and Manage Remote Teams, where I distill all the techniques I've been using to build and manage distributed teams for the past 10 years.

I write about:

announcement blogging book book review book reviews books building Sano Business C# Clojure ClojureScript Common Lisp database Debian Esperanto Git ham radio history idea Java Kubuntu Lisp management Non-Fiction OpenID programming Python Radio Society of Great Britain Rails rant re-frame release Ruby Ruby on Rails Sano science science fiction security self-help Star Trek technology Ubuntu web Windows WordPress

I've been writing for a while:


%d bloggers like this: