Afraid to Commit


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.
Published 09-28-2006 12:39 AM by jop
Filed under:

Comments

# re: Afraid to Commit

I guess that's an inherent problem with any version control system(at least Svn) there's no switch to obligated developers to commit everyday or on a specific schedule. If there was no switch for svn to force developers to enter a log message(you can even force it to a specific length) maybe most of the time this can be overlooked.

Going to the issue at hand, this can be solved by company or department policy and a strict implementation of that policy. Developing short of a wrapper for svn, when monitoring checkouts and forcing commits I guess a policy is a first step.

Wednesday, September 27, 2006 11:10 PM by bonskijr

# re: Afraid to Commit

Yes, we can go that way and force developers to commit code. Clearcase has a command line utility, cleartool, that you can use for finding out which files are checked out and which of these have exceeded the allowed "checkout" time. Just schedule this to run every hour and then send out emails to the "perpetrators".

That, however, is just curing the symptom. The real cause is the fear of developers to commit their code. I've worked with developers who would check out the code and then implement a lot of functionality without checking in. Unless someone else needs a file that he's got checked out, he won't release the lock. There is even one developer who likes his files checked out all the time. He regularly checks in his code but immediately checks it out again. When I asked him why he's doing it, his answer was "so no one can check it out before me."

I guess that's the reason why I like svn so much. With svn, you can check out you code, but there are no locks on the files. Everyone can use it and everyone can modify it. The longer you hold on to your changes before checking in, the bigger the chance that someone will change the file and commit it before you do. Then, you'll have a hard time merging your changes. Sometimes, the code changes are so radical that it is better to just undo their checkouts and re-implement their stuff. In that case, they'll start feeling more afraid NOT checking in their work.

Too bad I can't use svn here.

Thursday, September 28, 2006 12:58 AM by jop