August 11, 2016

ClearCase Migrations in 2016


Once upon a time, I was enamored with ClearCase.  In 1994 when I first started using it, I’d say it was the best version management system on the planet, the only one at the time that truly understood just how important branching and merging were.  Branching (easy) and merging (not so easy) enable effective collaboration of the efforts of large numbers of software developers.  But over the years, dealing with the excessive complexity and poor performance of ClearCase made it unbearable to use.

I first discovered and fell in love with Perforce in 1999. I’ve joked over the years since that the only thing I’ve done with ClearCase since then has been to rescue people from it.  And I’ve done a lot of that over the last 17 years, at times working with two or three migration projects for different customers concurrently.


A Love Story

Part of what made me fall in love with Perforce way back then was that it had the same strengths I’d come to enjoy (and expect) from version control from having used ClearCase.  But where ClearCase had lots of user-visible complexity whether you liked it or not, Perforce seemed to have been built with more of a “Pay as you go” attitude toward the sophistication/complexity trade-off.  If your needs were simple, you could be up and running in a day or so with Perforce.  If you have to manage the contributions of thousands of users across the globe, Perforce has the chops in terms of sophistication, performance and features to meet the diverse needs of complex global teams.


Driven by Competition

In recent years, driven by competition from the likes of git, Perforce has further evolved.  Where it used to take as little as “a day or so” to get started with Perforce, now it’s got to be more like “a second or so” with DVCS workflows.  With p4 init, much like git init.


These days, folks looking to leave ClearCase are generally looking at either a) Going directly to Perforce, sticking with the familiar central version control model, or b) Going to distributed version control model using some combination of Perforce (possibly with its own built in DVCS features), or Git with some Git repository management solution.  Perforce is one of several key players in the Git repository management space.  Perforce is uniquely positioned as the only solution with a mono-repo engine on the back end, which has some compelling advantages today.  And there’s more to come in the 2016.2 release due out later this year.


Perforce Keeps Getting Better

ClearCase hasn’t changed all that much since I started using Perforce.  Meanwhile, Perforce has evolved continuously, driven as much by competition as much as anything else.


Top 3 Perforce features for ex-ClearCase Users to know about Perforce:

·      Formatted Output:  Play with p4 –ztag –F formatted output.  It’s a rough moral equivalent of ClearCase formatted output, enabling scripts and users to interact far more efficiently with the version control server.

·      Triggers:  ClearCase administrators are often a bit trigger happy, developing various triggers to help guide development processes, with policy enforcement and/or best practices guidance coming in the form of custom triggers.  Perforce has similar capabilities.

·      Streams:  The powerful graphically guided workflows of Perforce Streams have are particularly compelling to ex-ClearCase users.


Perforce Migrations Keep Getting Better

Perforce Support and Consulting organizations help customers migrate from a wide variety of legacy version control systems all the time, ClearCase being among the many well-trodden paths to Perforce.

The Baseline and Branch Import (BBI) strategy remains most popular migration strategy for a customer’s migration from ClearCase, with significant improvement in the related tooling in recent years.  That includes the addition of Streams support.  For more info on that, follow the P4BBI project in The Workshop:

And for those who want every bit of detail that can be extracted from ClearCase, detailed history imports (DHI) are possible as well.  We often work with our partner, VIZIM Worldwide, when doing detailed history import migrations.


Trunk Based Development?

I know of some customers using trunk-based development strategies, essentially the “We don’t need no stink’n branches” philosophy.  Authors in that space point out that, even with good tools, merging can be hard.  And merging is insanely hard if you’re stuck with using poor merging tools.  But given options like Perforce and Git (which can be backed by Perforce), availability of good merging tools is not a challenge in 2016.

It’s true enough that merging can be hard even with good tools.  But I get the sense that folks may be overacting to bad experiences with tools lacking good merging capability (Subversion, CVS).  Folks coming from ClearCase understand what good merging is like.

A great thing about Perforce is that it supports a wide variety of branching strategies, and has a lot to offer regardless of whether you’re heavy into branching or trying to avoid branching.