I've used ClearCase for years as well as many others. Perforce being the other big commercial one. What I don't like about it are: 
1) The high cost for licensing 
2) The complexity involved - config-specs is a language in itself.
3) Difficulty in training employees to understand and use it properly.
4) Interoperability issues between remote sites.

[download]
One feature I can't find in any other VCS system is the build auditing CC does. With clearaudit, you can monitor any I/O that occurs while a program accesses ClearCase. We have automated builds that record every single file/version that goes into experimental builds and the product, for all time.

If we needed to apply a 1-line fix to a product released 5 years ago, we can do it in a couple clicks, compare against the last release and be assured nothing else changed.

The API provided by ClearCase is really extensive too, which I don't see as much in other VCS - Perforce being an exception. So now we've got tons of custom little tools all built around CC that'd make it difficult to switch.

At home I play around with SVN, Mercurial, Git etc. What I really like about SVN is the 3rd party support it has. When I fire up different IDEs, typically they have built-in support for only a few VCSs: CVS, Perforce, ClearCase, and SVN. Can't say that for mercurial/git.

I see lots of people praising git but if I was going to use something like that I really prefer Mercurial over it by a longshot. Git is simply way too cumbersome to understand & use than mercurial which "just works" way more often. I shouldn't have to become an expert in VCS internals and waste my time banging in the right magic commands and switches just to do something that should be easy.

Recently spent some considerable time trying to figure out if we could switch away from ClearCase to something like SVN, Git or Mercurial and the conclusion was unfortunately 'no'. Ideally I'd really like a system that: 
1) Had an extensive API
2) Had build auditing
3) Worked well on Windows as well as *nix (git fails here)
4) Had great easy-to-use GUIs so 'normal' people could actually use th
+e system to do most tasks.
5) Had some authentication/cryptographic guarantees built into the sys
+tem by design (git, mercurial do - nearly everything else doesn't)
6) Had an efficient way to work in a distributed way among disparate o
+ffices/developers
7) Had the ability to do renames and merges at a very granular level, 
+while also retaining historical info.
8) Provided granular access privileges to parts of the system (some th
+ings must be secret - think gov't work)
9) Changes can be applied/reverted/rolled-back in a single transaction
+ (atomicity) if desired.

[download]

In reply to Re: [OT] Evaluating version control systems by Zadeh
in thread Evaluating version control systems by Nkuvu

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.