[p4] ClearCase vs. Perforce

[Kevin Bailey]

On Fri, Jun 08, 2001 at 01:11:37PM -0700, Karr, David wrote:
> 
> I wasn't going to respond to this originally, because I don't consider
> myself an expert, but I can't believe some of the things you say here,
> without any data to back them up.

I don't know what you mean by 'data' but this is my experience.

> Version management in ClearCase is extremely powerful.  Whether you're
> talking about the "version" of a system, or revisions of particular
> elements, there is a great deal of flexibility available.  I wouldn't say
> this is easy to use out of the box, but if you design a development
> environment that facilitates this, you will have a great deal of power.

In the system I used, Clearcase didn't have the concept of a
change-list. The build was constantly broken because people
would only check-in 4 out of 5 files necessary for a fix. They
would subsequently do the same thing when merging the fix to
another branch.

> The "version" of a system or the mapping to element revisions can be
> modified by changing a single file (configspec), and as ClearCase uses a
> file system driver to provide access to elements, after changing the
> configspec, it instantly changes the version mapping you see in your file
> system.

Isn't it true that when you change the config spec and the version
of a file mapped in changes, that the timestamp on the file goes
to when the file was checked in, not to when the config spec was
changed ?

And isn't it true that every make in the world (except Clearmake
of course and, I suppose, makepp) will then fail to recognize
that the file needs recompilation ?

> Directories in ClearCase can be versioned, which is a feature missing in
> Perforce and CVS.

I for one haven't needed that feature yet.

> With respect to "build management", ClearCase certainly lets you "pick
> tools", juat as with Perforce.  However, if you use their "make", which is
> an enhanced clone of GNU make

Clearmake is missing many features of gmake. It is NOT a drop-in
replacement.

> ClearCase provides even more power, as it
> provides for the ability for "derived objects" (object files, libraries,
> executables, etc.) to be mapped to "config records", which describe exactly
> what versions of "dependent objects" were used to build those objects.  This
> is done automatically, under the covers, by the ClearCase file system driver
> while watching file manipulations.

Unfortunate if he wants to use pmake or the like.

> With respect to "ease of use", I would certainly admit that with its large
> number of features, it has a high learning curve, and out of the box is
> probably difficult to use and administer.  However, it's considerable
> flexibility allows CM engineers to build development environments that make
> it much easier to use.  Even without that, the ClearCase GUI tools for
> viewing branch histories and for merging element revisions are much better
> than you can get OOTB with Perforce.
> 
> In the last large ClearCase project I worked on, the ClearCase administrator
> left, because there was nothing left to do, and the system just didn't
> break.

In the last "large" Clearcase project I worked on, the
administrator (a Clearcase expert, supposedly) took 4 months to
set the system up and even after that was constantly running
from desk to desk helping people. Productivity was cut at least
in half.

> The cost of ClearCase vs. Perforce is certainly an important factor.
> However, I've only been using Perforce for a few months now, but I guess I'm
> not sure what the real value of Perforce over CVS is.

Speed, atomic transactions, change lists, better branching, keeping
track of already merged changes, ...  There's no comparison.

My 2 cents,
krb