I have been a ClearCase administrator since version 1.2 was out back
when the company behind it was called Atria. That was before it merged
with Pure, got bought by Rational which was gobbled up by IBM.
ClearCase's biggest advantage were dynamic views. Dynamic views
completely changed the way you look at CM. With ClearCase, there was
no "working directory". You worked in the archive, you saw all the
files in the archive, you could compile, use the standard Unix tools,
do source code analysis, etc. The only thing you couldn't do was edit
a file until you did a checkout.
Dynamic views had all sorts of neat tricks. For example, you could
"cd" into a history tree of a given file by appending "@@" at the end
of the name. This allowed you to search all versions of a file for a
particular change.
When ClearCase switched to static (aka snapshot) views, the magic was
gone. Instead, you had all the headaches of having a separate working
directory with all the disadvantages of creating configspecs. Yes,
dynamic views still exist, but they are slower so most people use
static views.
Static views don't use the ConfigRecord build avoidance (this is where
if someone else built an object with the same configSpec and the same
base files, ClearCase would "winkin" the built object into your view
instead of actually doing the build). This might be a hidden blessing
because ClearCase's build avoidance has problems with Ant and some
implementations of C++.
Although Static views lose most of the advantages of dynamic views in
ClearCase, they still need to talk to the server when doing such
things as a checkout. You can get around this problem by "hijacking" a
file (by changing it from "read only" to "read/write") but fixing
hijacked files can be messy.
The biggest headache in ClearCase is the ConfigSpec. This is the
specification you use to explain exactly what you want to see in your
view. It is a pain the the lower anatomical region and you usually do
everything in your power to make sure users don't set their own views.
A single incorrect ConfigSpec can cause unbelievable damage to a
project.
ClearCase's big advantage is its triggers. A trigger is like a hook in
Subversion, except you could have triggers for almost any action in
ClearCase. Triggers could fire before an action took place or after it
took place. Unfortunately, triggers are slow. Even worse, they run on
the local machine. That means you have to design your trigger script
to run on all possible client configurations and install the right
version of any scripting language you depend upon. That pretty much
rules out using ClearCase on the user's home systems for remote work.
ClearCase's UCM was an attempt to establish a solid development method
on top of ClearCase. The idea is excellent, and the newer versions of
UCM are much better than the older version that was buggy, slow, and
prone to breakage. However, UCM is extremely complex and trying to
untangle a simple development mistake can take the better part of the
afternoon to fix.
ClearCase's Windows implementation uses Windows Explorer much like
TortoiseSVN does. There is also a separate ClearCase explorer that can
be used which can show more details. The ClearCase Unix implementation
is much more primative and most Unix users prefer the command line
interface anyway. If you use ClearCase UCM, you do not use the Windows
Explorer GUI. Instead, you use the special ClearCase UCM GUI.
Here's where I see ClearCase's big advantages over Subversion:
* Triggers are much more detailed and powerful than Subversion's
hooks. ClearCase has the ability to allow for triggers to query users
for additional information while they run.
* Merging: ClearCase's GUI merging facility (in both Unix and Windows)
is very simple to use. ClearCase doesn't allow "cherry picking" which
is not the greatest of practices anyway. ClearCase marks the merge
with a type of record called a "hyperlink". Because of this, ClearCase
knows what versions of a file were previously merged into the working
copy. I've rarely seen a ClearCase merge go bad.
* ClearCase is much better at tracking file and directory changes than
Subversion. ClearCase understands file renames and moves and a request
for history on a particular file can be easily traced both ways.
* ClearCase query facilities are much better. You can easily find when
a merge was done, who did a particular change, when a particular
attribute (what Subversion calls a property) was placed on a file,
etc. With Subversion, you have to depend upon the log file output and
do the parsing yourself.
* Branching: ClearCase branches are true branches and not simply
directories as in Subversion. Because of this, merging, diffing, and
viewing a file's history is very simple. Like Subversion, ClearCase
branches are "cheap" and invoked by name instead of using a numbering
scheme like RCS or SCCS. Most developers do all of their work on their
own branches, then merge their code onto the main branch once they've
completed their work. Infact, UCM institutes this practice of side
branch development.
Here are ClearCase's biggest disadvantages:
* Triggers: A trigger has to be able to run on the client in order for
it to work. That means you have to maintain and install a whole slew
of software on your various client machines. About 50% of the trigger
problems are the results of the trigger script failing because the
client machine is not running the correct version of the software.
* ConfigSpecs: A pain in the rear and probably the biggest reason why
UCM was created. One developer with a single bad line in their
ConfigSpec can cause a ton of grief.
* Resource Hog: When configuring a ClearCase system, you simply say
"What's the biggest, most costly system I can think of?", and then
double it. There is no way in the world to underestimate the size of
what you need with ClearCase. We ClearCase administrators use to joke:
* New high speed 1gigabit Ethernet network: $1,500,000
* New Server for VOB and view storage plus needed RAID array: $300,000
* NetApps server: $90,000
* Comvault backup device: $250,000
* The fact that ClearCase is so complex and impossible to understand
that the whole project would ground to a halt without you, so you have
job security for life: Priceless.
I see Subversion as being a bit green. The fact that branching and
labeling aren't built in concepts, but implemented as directories is
probably the biggest problem with Subversion right now. Because of
this, simple things like taking the diff of a file or doing a merge
can be quite complex.
Merging is also another issue in Subversion. Subversion doesn't track
what versions were already included in a merge and finding this
information can be difficult. Especially if users don't setup their
log messages the right way. Subversion also doesn't do directory
merging which is a problem for a package that tracks changes in the
directory structure.
Subversion still doesn't quite track directory or file name changes
since it considers moves and renames a "delete and add" (although
because of this, doesn't suffer from ClearCase's Evil Twins problem).
Other Subversion problems include being unable to remove unneeded
versions of files from the archive. If someone accidentally adds a
file in the archive with information that shouldn't be shared, there
is no way to easily remove it from the archive. If a site versions
binary data, they cannot remove older versions that are no longer
needed. Thus causing the size of the archive to waste space.
Still, Subversion has a lot going for it:
* It is available on a lot more platforms than ClearCase
* It is easy to use and install -- especially on client machines.
* Network security: Subversion can use https or svn+ssh which make it
safe to use remotely. ClearCase has to be used via VPN to be truly
secure and some setups of VPN filter ClearCase packets out.
* Subversion is much faster and leaner.
* Subversion makes a clear distinction between the client and server.
An administrator only has to worry about the Subversion server
installation and not how the clients are setup.
* The price is right.
I might not want to install Subversion on a site with several dozen
developers churning away at a single project, but those types of
projects are few and far between. Most projects now consist of fewer
than a dozen developers doing rapid development. For such a small
project, ClearCase is a big headache since it requires large overhead.
Yes, I realize that the Subversion project itself and other open
source projects such as Apache are in fact large projects with dozens
if not hundreds of developers successfully using Subversion as their
version control system. However, the open source community is a bit
different from a corporate environment. Besides, ClearCase is hell to
setup for a massive remote development effort. That's why there's
ClearCase MultiSite.
ClearCase is still the preferred package for very large development
shops because it allows for such centralized control and IT shops love
it because it gives them power to overlord all development efforts.
But, after administering ClearCase for 15 years, I am not convinced
that it is the right package for most development efforts anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 5 19:36:14 2005