I attended a Configuration Management Training Course at work today. Rational ClearCase is the software sanctioned by the company. When my outlook client told me about a training invite on my inbox, I was surprised to see that the training is scheduled to take one whole day. Why on earth would I spend one day learning just a version control system?
I turned out that ClearCase is a very complicated beast. Before you can effectively use it, you need to be familiar with VOBs, views, elements and config specs, rules, dynamic and snapshot views, label types, branch types, etc. Even then, you need to understand the proper way of checking out and checking in stuff, reserved and unreserved checkouts, using tools like ClearCase Explorer, Clearcase Type Explorer, Merge Wizard, Apply Label Wizard, and a whole boat load of stuff. Abstraction leaks everywhere.
However, this is not the point of this post.
About halfway through the training, one of the attendees started crying out his emotions regarding one of his bad experiences with ClearCase. On a previous project, he and his team lost a weeks worth of work when their ClearCase views got corrupted. Let’s just say that a ClearCase view is database of sorts that ClearCase uses to store files that are not yet checked in. It can be located either on a drive on your local machine or on a shared network folder. In the case of the attendee’s team, their views are all stored on a shared network folder. The drive containing the folder got corrupted, and all the files that they’ve checkout and modified were swooshed.
Let’s skip the fact that the clearcase view got corrupted (sh*t happens) and move on to a more important point. Why do they have weeks of uncommitted work in their views? If they only checked in their code before going home, the effect of the corruption would not be as bad. Of course, it still is a days work down the drain, but at least that is not a weeks worth. For a team of 5 people, that is a lot of man hours.
I talked to my some of my colleagues and it looks like it is not and isolated case. What are these developers afraid of? What can’t they just commit or check in their work at least once a day?
It has always been my habit to check in files whenever I’m done with something that I have been working on. Before TDD, that was at least once a day. When I started doing TDD, commit happens at least once an hour. If I am doing lots of refactoring, I am committing code after each and every refactoring: every few minutes. I’d like to think that I’m just getting better; that’s why I’m committing more frequently. But I think real reason is because of TDD, I now have a better feeling of when I am done.