Some links can be found both from the IBM web site, and from several independent sources.
Here are a few aceptable (if questionable nevertheless) examples:
- Eviltwintrigger: try to prevent the creation of evil twins (see BccFaq1_2_8) by looking in the version tree of the parent directory element
- Force directories to be group writable, to workaround users' wrong umask (note: protection events are or not replicated, depending on the preserving mode of replica objects...)
- Remove branches with only a 0 version on
uncheckout
A few typical bad examples:
- Enforce a naming policy for branch or label types (beyond lowercase for branches and uppercase for labels...)
- Prevent users from running
rmelem or rmver (the dangerous cases are mostly prevented already, so this prevents only the useful ones, e.g. cleaning up right after a mass import to the wrong directory, thus of evil twins)
Triggers are often overused, often for wrong reasons, such as for
process enforcement, which most of the time, directly conflicts against
management.
Triggers are not always practical.
There are problems of performance: they are expensive,
and more fundamental problems yet.
And triggers are weak and therefore dangerous in general.
Triggers are a way to prototype functionality you'd want the next version of
ClearCase to support.
That's about all.
Of course,
ClearCase development is mostly over, and the next version is unlikely to contain the changes you wish for.
[Note: I extracted this page (empty) from the
BasicClearCase page, in order to make corrections to it in a manageable way --
MarcGirod - 02 Sep 2007]
CM Web
Log In