The one historic feature that ClearCase has over its competitor is the dynamic views: that MVFS (Multi Version fileSystem) allowing to access files over the network rather than downloading them on the hard drive.
This is not the only way to work with those files: you can combine snapshot views (your classical "workspace") and dynamic views, but it is really useful.
The other powerful features are are based on simple concepts:
- branch is a first-class citizen (and not just a "directory" like CVS or SVN)
- tag is not the same than branch
- Version tree is simple and intuitive to understand.
- lazy branching allows you to easily create a branch and isolate whatever development you need.
- directories are managed in version control like files are: remove a file and it is actually the history of the parent directory that changes (simple dereferencing).
Then there is UCM (Unified Change Management) which introduces some interesting best practices (like the baselines: a label put on a complete set of file: the component, and which can not be moved - that avoid nasty surprises ;) -)
In my opinion, a correct use of UCM is the fastest way to leverage ClearCase features, provided you use the UCM streams (set of labels, and pattern for branches) wisely, that is to represent a development effort (current dev, patch, refactoring, assembly, ...), and not just to build a private workspace for a development: myStream is wrong: stream_dev is better. (If you have 15 developers with their own streams, you set yourself for countless merges back and force between the different branches associates with those streams!).
Basic rule of thumb: the name of a stream must represent a development effort, not the name of a resource (developer). The effort is here to stay, the developer can come and go.
The other best practice is the merges in UCM: they come with their own semantic based on the stream organization: "deliver" for merge from sub-stream to other streams, "rebase" for merges from parent stream to child stream.
In the end, those are still classical merges, but I find them very easy to explain to developers, and they can organize their "workflow of merges" based on a true development lifecycle very easily.
The notion of activity (or changeset) comes also in UCM and is very useful to detail his/her work.
I will not detail here the drawbacks and quirks of ClearCase since it is not the question ;)