ClearCase is bad, and I don't like it

I don't do many technical posts, but I was writing this in an email anyway and thought I may as well publish it.

The main ClearCase-rooted things that hurt me on a daily basis at the current client:

• No atomic check-ins and frequent hangs during check-in/add (maybe a network/machine issue rather than CCase) → many broken builds. (I suspect ClearCase doesn't respond accurately when Cruise checks to see if there's been activity during the (120-second) quiet period.*)
• No tool support for seeing all at once what needs to be synched between the local snapshot and the repository (combined w/ lack of atomic check-ins) → many missed file-adds → many broken builds.
• Complexity of administration → this is handled (in a giant company) by some support team only reachable via support tickets → slow resolution of issues, which, due perhaps to corporate stinginess with permissions, includes restoring deleted files and undoing absent users' checkouts.
• One-file-at-a-time labelling → labelling the code-base takes hours → it's a once-an-iteration operation rather than an every-build operation → no ability to pull the most recent known-good code → devs who update before seeing that the build is broken** have to manually roll back individual files or be locally broken until the broken build is resolved.
• One-file-at-a-time up-to-date checks → updating is slower than it ought to be.

* On further thought, it's more likely we're seeing:

• 1: Cruise checks for activity,
• 2: ClearCase responds that there's been none,
• 3 and 4 in whichever order: Cruise starts updating; I start checking in,
• 5: Cruise ends up with only some of my check-in,
• 6: Cruise builds with whatever chunk of my check-in it got, and that not surprisingly fails more often than not

** ... or while Cruise is building or the relevant build is queued behind other builds.

tagged clearcase scm dev