The 'Best' Revison Control Software

One of the teams at work is currently evaluating which revision control software (RCS) product to use as we are moving away for their preferred choice of ClearCase. I've never understood ClearCase and have, in a couple of companies, been perplexed by the strong passion for ClearCase that some teams have had. But, after observing the guys at work evaluating different products the penny has dropped for me on how ClearCase can, truly, be the best RCS software.

There are many revision control tools like subversion (SVN), ClearCase, Perforce, etc, and their functionality varies greatly. No one product that I know of does everything. Interestingly when I worked at a GE company one team used SourceSafe, another used ClearCase, and the other used (I think) Perforce. I've tried to use ClearCase and found that it greatly reduced my productivity. But yet, others insist it is an enabler. How can this be so, we are all software developers, right?

Taking ClearCase as the example here, at my current work we have a team that sees ClearCase as important to their success while others see it as a blocker. I think I can explain this from why I find it a blocker and from what I've learnt as to why this other team sees it as an enabler.

ClearCase as an blocker

I like to work in an agile fashion and in particular in a eXtreme Programming (XP) style. It suites me, I perform my best this way. So the style that works for me includes the attributes of:

• Continuous Integration (CI)


• Ruthless refactoring


• Teamwork

This translates to a process of:

• Commit code to the repository about every 30 minutes (average on a good day).


• Merge from the repository every 15 minutes (keep up to date with the rest of team's commits).


• Do not work on branches.

ClearCase is very feature rich. Trouble is that these features make the process above impossible. The features are actually detrimental to this way of working. The fundamental problem is that ClearCase, one way or the other, enforces a level of isolation so that each commit requires multiple steps. The end result is that it takes minutes to do a simple merge and commit with ClearCase. If CI is being used the superior merging capabilities offered by ClearCase's process have no benefit as the merges are always small.

So I find that for an XPish way of working ClearCase's features do not translate to benefits.

ClearCase as an enabler

The other team, I mentioned at the start, however considers ClearCase's features to be important enablers to their work. I admit that at first I did think that were a 'crazy' but I've come around and recon they are right. After all, they are a successful team so how can they be wrong!

I see them as agile as they are collaborative but their work style is nothing like XP. The style that works for them includes the attributes of:

• Non-CI. Each developer works in a branch with, what I consider infrequent (but that is qualitative) merging.


• Up front design approach (I think).


• Teamwork.


• Little or no refactoring. (Refactoring is seen as a result of failure as opposed to my style of it being an enabler.)


• Low requirement churn.

This translates to a process of:

• Infrequent commits. I'm guessing an average of once every 2 days.


• Careful merging (essential with infrequent commits).


• Detailed history records of merges to trunk as this is the 'delivery' and work is usually on a branch.

So, interestingly, SubVersion's (my favourite) features do not translate to benefits for them just like ClearCase didn't for me. For example, SubVersion is fast but they do not really need speed. The big blocker for them is that SubVersion does not currently (scheduled for ver 1.5) record merge history. That is, when a branch is merged to trunk. This is their basic work practice!

So, for them, ClearCase is the best as it matches a work style that works for them.

Conclusion

I really should have known better, people always trump process. People and environments are different so there is no one right way of working.

My spin on this: Now that agile software development is proven and wide spread, Agilists are at risk of now becoming the ones that say 'one size fits all'.