Internally it's a very powerful versioning filesystem which presents different views dynamically to each user. Externally, it is an NFS server. This means that if you and I both look at a code repository, for example, we can do so from any machine and it'll work.
There are also command line and GUI tools to handle branching and merging, and so on. Absolutely beautiful.
Sorry if all that sounds like buzzwords for folks unfamiliar with the above terms. If youre not, I'm afraid you'll just have to trust me that these are bona-fide features used by a great many real world shops every day (which by no means should imply that your particular shop has need of them, it well may not).
Now for the bad stuff (and there is plenty to go around). It has a steep learning curve for those trying to administer and roll-out their own custom-deployed process of triggers & wrappers (actually, this is only true for *base* ClearCase -- not so for UCM ClearCase) . And the administrative overhead for ClearCase is exorbitant. It requires darn near full-time administration most of the time (sometimes a whole team for large projects in the 100 or more people range). -- BradAppleton
What is it about ClearCase that requires so much time for administration? I hear a lot of people say that there is a lot of administrative overhead, but no one ever says specifically what takes so much effort. -- KenLiu
ClearCase admin should be a full time job! - If you want to manage a bigger project, you should have a well trained and experienced ClearCase admin and you will manage to drive big projects with only one or 2 admins. We do projects distributed over 3 sites with more than 100 SW developers (8 Million NCSLs) and about 50 HW/ASIC developers - including all documentation and project management docs with only one admin. -- firstname.lastname@example.org
Dynamic views are extremely network intensive; forget about telecommuting. -- WillSargent
The alternative is ClearCase MultiSite. Snapshot views and MultiSite are on both ends of an axis to support what you call telecommuting. There is probably a MissingSynthesis between the two. -- MarcGirod
Snapshot views are good for telecommuting, and for organizations which like to decouple developers a bit. MultiSite is for organizations with multiple development sites--just like it sounds like.
Base ClearCase does not have support for batch operations (submitting several files under one change, comparing one labeled branch with another etc.)
V4.0 and later versions of ClearCase support "change sets". For comparing labelled versions, the ClearCase equivalent of the "find" command will do that for you... of course, you have to understand find(1) and its Clearcase equivalent.
I'm glad to hear that CC caught up with more modern version control tools (I'm glad because I'm forced to use CC in my day-to-day work). I'm not sure which version of CC I have, being on the client end, but it heartens me to think that there might be a newer, faster version of the thing waiting to be installed one day. Before using CC I used Perforce which was much simpler.
Clearcase has a built-in process called UCM, based on RUP, that is a more process and object-oriented approach to source control. The latest version of Clearcase, and its "lite" version, are both very good. Yes, it is a resource-hog; yes, it has a steep learning curve. However, overall, we feel that it takes care of a lot of the work and process that would be manually required for something like CVS.
ClearCase file system
If you're considering ClearCase, check out Perforce first. Way,way cheaper. 90% as functional.
Forget it! What I like about ClearCase is not that it is the world's best source code revision control system, what I like is that it is a filesystem.
Nothing that is not a filesystem can compete with ClearCase in that, its central strength.
However, for people who dislike the filesystem aspect, you may as well list the features that you think make it better than the thousands of competing products/freeware systems.
I would be interested to hear what advantages you think the built-in filesystem lends.
I imagine you are talking about ClearCase dynamic views. These are quite handy for storing project documents, released software packages and the like; a file system being a project manager friendly interface. But for source code control?
I've seen a few attempts at using dynamic views for source code control. The biggest problems have been the speed of compilation. On a dynamic view compilation took around 4hrs compared to 20mins on a snapshot view. Also, if I remember rightly, there was some extra administrative overhead to prevent conflicts (private branches?)
Snapshot views in ClearCase are like those of PerforceVersionControl and can be used for source code control. But when it comes to snapshot views, I would say that Perforce has the upper hand here in terms of speed and usability. -- ChrisSteinbach
What are the clients available?
All the usual platforms - Linux, Solaris, HP-UX, Windows, et al <http://www-1.ibm.com/support/docview.wss?uid=swg21136950>
I'm using ClearCase again after a long hiatus, and I'm confused. How do you add a file to source control as a part of an atomic checkin including a set of other changes?
What's the best practice process for using reserved checkouts? Currently, we're doing the following:
update the view, run merge manager (TOO SLOW), check out directories with added/removed files by hand, add/remove those files, then check in.
getting strange messages from ClearCase during the merge manager step, it asks about checking in a "checkpoint" copy of the file - where does that get checked in to? if somebody updates their view after I do this save checkpoint, but before I check in my changes as a whole, can they see the checkpoint version? -- JeffBay
Worth checking out the ClearCase remote Client <www.clearcase.co.uk>
(Truth in posting: Perforce hired me to write a whitepaper on why Perforce was so much better than ClearCase; I didn't feel the need to lie) The filesystem mounting is ClearCase's greatest achievement and its greatest weakness. It is good at keeping you from accidentally writing new files and forgetting to add them to source control. It could theoretically save compile time by "winking in" object files that it's compiled with the same set of sources, but that's less relevant as the speed difference between compilers and hard drives increases. But if you set Git (or any other source control) up as a filesystem, then every file read becomes an SCM hit. So if you're writing in C and have a header that's used in 500 source files, that's 500 Git requests to serve that one file during a compile. You don't want to know how many file reads a C compiler does in a medium sized project. Maybe Git is fast enough to handle this, maybe not. I do know that I've had ClearCase installations where it took ten minutes to get a directory listing. --RobMandeville
"But if you set Git (or any other source control) up as a filesystem" - What does that mean in the context of git or any other DVCS? -- DonBranson
Maybe something using FUSE like http://github.com/rossbiro/GitFS