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