Re: Converting ClearCase to CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>--- "Mark A. Flacy" <address@hidden> wrote:
>> Out of curiosity, why are you moving from ClearCase to CVS?

>Okay, you asked. Here it comes. But my question would be why not move from
>ClearCase to CVS? This comes from my personal experience at multiple clients,
>some using CVS, some CC, some both. 

>ClearCase has:

>- much large cost of tool and support (I think their in kohuts with $Oracle$
>and that they are learning software development and customer relations from
>Microsoft)

You get what you pay for.  In my opinion, the quality of implementation
of ClearCase is much more robust than CVS, and Rational supports it much
better anyone supports CVS.

>- much more money to shell out if you need to work at different locations
>without depending "always on" conection over a network, to simulate the
>unwritten rule that the client and server need to be (logically) on the same
>machine to work. (even if you use multisite, you get to the added benefit of
>needing merge everything on each end, which kills most if not all benefit of
>multisite if both sites need to work on the same release/branch)

This much is true.

>- a much larger "tool admin" to "project/user" ratio. Are you spending more
>time on CM activities or babysitting the tool? Does you phone ring for CM
>issues or CC issues? Do your users that just want to checkin their work without
>needing a PhD from $Rational University$ 

At my current employer, our user-to-admin ratio is over 50-1.  And all of
our users are competent enough with ClearCase in half an hour to create and
configure workspaces and to perform checkouts, checkins, merges, and
version history queries.  This is even if they've never seen ClearCase
before.

>- cannot handle interopability, yes Virginia, you must purchase or obtain yet
>another tool to assist CC, and add that to your overhead activities to maintain
>this tool to compensate/help out CC. (how much did you spend on CC and how much
>is it still costing you per day?)

This is true if your shop does development on both Windows and Unix.
However, one of the supported interop tools is Samba, which the IT
organization probably administers anyway.

>- much more larger (and persistent) learning curve (and ongoing user
>frustration level, especially if the out-of-touch high level people that where
>sold the tool where also sold on UCM, the so called "out-of-the-box" solution)

Then don't use UCM.  It's too immature for large development efforts, and
Rational doesn't push it for that.  They also realize established development
efforts already have their own processes, and support deploying them using
the pre-UCM feature set.

>- no additional functional benefit do to "directory versioning", cvs add/remove
>per branch per file is suffiently equivalent/reasonable. (continue reading if
>you want to reply to this one about renames and moves) don't get me wrong, I
>think directory version is great, but its importance in the grand scheme of
>things is artificially inflated.

In your world, not mine...  If you're used to (and willing to continue)
working around its absence, you lose sight of its value.

>- cost/amount of infrastructure that is needed, CPU/bandwith/servers. Its
>expensive to keep performance up. contrary to what you may find on CCUIG,
>clearcase is anything but efficient when it comes to disk space. You have the
>VOB and all versions, fine, but the VOB also has cache it maintains to send
>files to views and you must regularly free it up to get back disk space. Views
>do not save on disk space, beacuse to use a file, it must be _copied_ into the
>view (just like CVS). but views have an added benefit, they can collect and
>store deltas in a cache for more that one version of the file, that must be
>cleaned up to get back disk space. Oh, you need to update a few files in you
>view, CC needs to continuously export a file system over the network to each
>client, CVS just sends packets with just the deltas needed, when needed. CC
>functionaly does what CVS does for updating views/workarea, CC just needs a lot
>more of everything (CPU/bandwith/diskspace) to do it and does it at a different
>time (at file use or checkout vs workarea creation). So if you never use or
>view a file in a CC view or have a bunch of garbage in your repostory you will
>never use in a build or development, then CC can be more efficient. How about
>all those processes CC has up and running, dragging down the system, just
>waiting around to be used (or begging to be restarted/bounced).

It's true that ClearCase does prefer bigger servers and more network
bandwidth, but your claims are a little inflated.  It doesn't need constant
tuning and hardware upgrades to maintain suitable performance.

VOBs store shared resources.  As such, they cache any files that are checked
in, plus other objects like built objects that have identical inputs
(sources, build rules, environment settings, and other things).  ClearCase
goes to great effort to minimize the replication of data within a single site.
Views contain private resources, such as checked-out files, and other
stuff no one wants to see outside the workspace.

That said, ClearCase databases do tend to be larger than CVS because they
store more stuff.  Relational databases store tags and other meta-data,
and indexing all that stuff takes space.  On the other hand, because the
relational database is there, access to all that metadata is way faster
than in CVS.

ClearCase does need to clean up its caches, but it comes out of the box
with the necessary administrative tools that install and schedule themselves.
My first server had 30GB and it lasted for 4 years, storing VOBs and build
views.

ClearCase does indeed export files over the network to all of the
client machines that need them, just like NFS does when a single CVS
workspace is shared among several machines.  If your workspace is hosted
on the same machine that you're logged in on, that overhead disappears.

Yes, ClearCase leaves a lot of server processes hanging around, but if
they're not used, they can always be stopped...

>- Trigger processing on the client, and all the maintenance fun that goes with
>it <yuck>. why can't you have integration prcoess ing done on the server and
>have a web based tracking tool and not worry about users client machine setup
>and configuration? well now we can.

Running triggers on the client is a trade-off.  It has the ability to
interact with the user, and its weight is lifted off the server.  On the
other hand, client machines do come in a wide variety of shapes and flavors,
so trigger scripts must be carefully written.  'Course, Perl comes with
ClearCase, and using it does go a long way to solving portability problems.

>- lousy vendor support, yes the CCUIG keeps rational in business, without it I
>think rational would be out of business.

Most commercial support teams don't provide the level of service that their
customers want.  But my personal experience with Rational has been very
favorable:  They have been very responsive to problems I've had, often more
responsive than I have been (i.e. they follow up faster than I can try
their recommendations).  And patches are generally available before I need
them.

>Okay, the way Clearcase stores elements is neat (hey, its a relational
>database), you can rename a element (the name is just metadata, like a
>tag/label is) and even track an elements movement around a repository (more
>data for the database). What's the value added benefit? When was the last time
>someone asked where a file was in the repository 5 months ago? Or, has this
>file had a different name before? Is the total cost to your business, by doing
>business with rational, worth being able to answer these silly questions?

The only time I've seen people make queries like this is when directory
versioning wasn't available to them, e.g. in a CVS shop.  This happens
when a bug turns up in an old release and needs to be fixed on a
maintenance branch, and the sources have been reorganized in the meantime.
It happens even more often when the guy doing the maintenance is new to
the organization.

With ClearCase, a common scenario takes this trouble away:  Configure a
workspace for current development, find the necessary file, then reconfigure
the workspace to the maintenance branch.  If the file and its parent
directory tracked each other through a reorg (which is common) then the
user's present working directory suddenly changes to the old location.

Add to that the fact that the file has a single version history over its
entire lifetime, merging across branches in the presence of reorgs
definitely makes ClearCase worth the price we pay for it.  The savings
in productivity to merge a complete patch from a maintenance branch to
the upcoming major release pay for the maintenance of ClearCase for the
developers involved for a year!  This is because they don't have to
do the version shuffle by hand, plus they have a much nicer merge tool.

>Then only thing going for ClearCase is merge tracking (UCM sure knows about
>this), that is really an asset. but coordinating merging in CVS isn't that bad.
>But if you branch for every silly thing, well... can't help that, we have a one
>to one relationship between branches and product releases, merging is minimal.
>Is all about planning, and ounce of CVS is worth a pound of CC.

>UCM - this is not a process, it is not CM, it is called change sets, its a tool
>function that has been implemented in the most convoluted way (adding a whole
>new command set and abstraction to protect you from you, I guess). Normally you
>connect to a tracking tool and tie file versions to a ticket/bug number
>whatever, for change sets. Why did they do UCM in ClearCase? don't know. Maybe
>they never learned the rule, "if it ain't broke don't fix it". Maybe they
>realized their bloated software does anything but work "out of the box", and
>making UCM is needed to hold people over till the army of CC/CQ admins, SAs and
>DBAs, can get things working right. But don't think about upgrading Oracle from
>8.1.34 to 8.1.35 cause your CQ is at 2001 and only 2001a can handle Oralce
>8.1.35. Oh, you need CQ 2001a, well that may not work with CC 4.1, you now need
>to upgrade to CC4.2. yadda yadda yadda. Okay previous versions where examples,
>but you get the picture? Rational must not know much about backward
>compatibility, OOD, where's RUP when you need it Rational?

Whenever there are large numbers of software packages involved in any effort,
there are bound to be compatibility issues.  Ask anyone who has an OEM
agreement for anything.

But your point is well taken, with this many tools, care must be taken to
keep them bundled and to coordinate upgrades accordingly.  And BTW,
Rational does care very much about backward compatibility:  It's rare
to be unable to mix versions of their products in a single site, if you
follow the documented migration path properly.

>Unless your a CMM level 5 company, writing software that affects lives, spend
>more time writting/following process than producing code, Rational tools, may
>actually be counter productive to your company. The ROI is not in sight and the
>gap is widening. Cutting loses and movin on. May need to re-image PCs to fully
>recover from rational. :)

>I used to compensate/cover for rational like other CC proponents, but Rational
>folks rubbed me the wrong way one to many times, now I call it like I see it.
>Okay, more of a rant, but does this answer your question?

Anyway, I see that you're sooo pissed off that you think that a less
capable tool will solve your problems.  Good luck to you.

>--- End of forwarded message from address@hidden