Highley Recommended, Inc.


CM Home
CM Resources
Getting Started
Config. Spec.
CM Procedures
New Project VOBs
CM Plan
ClearCase Best Practices
ClearCase FAQ

Table of Contents

Trigger Installation
Uninstalling Triggers
Trigger Debugging and Other Information
Triggers and Authorization Lists
Branching Policies
Labeling Policies
Mail Notification

The design of these triggers is based on having a fine grain of Configuration Management control. For every ClearCase operation you can define who is allowed to perform this operation. There are three levels to this authority, in priority they are; all, scope, and other. An example of scope could be a branch, so you can have multiple scope user lists.

Trigger Installation

To install the triggers in a new VOB follow the instructions below.


  1. cd /home/ClearCase/process/triggers
  2. Install VobTag - Will install all triggers in a VOB.
  3. pre_ci_trig -install VobTag; Install only this trigger.
  4. pre_ci_trig - Displays trigger documentation.


  1. Start a view if needed.
  2. Run Command Prompt
  3. \\oak\ClearCase\process\triggers\Install.bat M:\viewtag\vobtag -
    Will install all triggers in a VOB.
  4. \\oak\ClearCase\process\triggers\pre_ci_trig.bat -install M:\viewtag\vobtag ;
    Install only this triggers.
  5. \\oak\ClearCase\process\triggers\pre_ci_trig.bat -
    Displays trigger documentation.

Trigger Documentation

Uninstalling Triggers

To uninstall the triggers in a new VOB follow the instructions below.


  1. cd /home/ClearCase/process/triggers
  2. Uninstall VobTag - Will uninstall all triggers in a VOB.
  3. pre_ci_trig -uninstall VobTag; Uninstall only this trigger.


  1. Start a view if needed.
  2. Run Command Prompt
  3. \\oak\ClearCase\process\triggers\Uninstall.bat M:\viewtag\vobtag -
    Will uninstall all triggers in a VOB.
  4. \\oak\ClearCase\process\triggers\pre_ci_trig.bat -uninstall M:\viewtag\vobtag ;
    uninstall only this triggers.

Trigger Debugging and Other Information

Trigger debug subroutine

A perl subroutine, com/TrigEnvs.pl, can be added to any trigger by:

        require "TrigEnvs.pl";

Adding the above two lines in the execution block of the trigger. It will create a file named "${NAME}.txt" in the current directory. NAME is the name of the trigger. This will allow you to see what ClearCase variable you have at your disposal for use in this trigger. For other problems add perl print statements.


Some triggers are a little more interesting. Be careful when modifying the post_mkelem_trig trigger. It needs to run setuid and setgid so that it can run the cleartool protect command to change the owner and group of new element created and the mode of new directories. Both the shell wrapper script post_mkelem_trig and the perl script post_mkelem_trig.bat need to have the setuid and setgid bits set, "-rwsr-sr-x". As of Solaris 2.6 a shell script with that is run with a setuid no longer has the $0 environment variable set to the name of the script. A path must be defined within the script or absolute paths need to be used for each external command executed. Perl requires every variable within a script that has data defined externally to be untainted, meaning parsed and the variables value replaced with the parsed results. Perl also seems to require that you re-parse a variable in a main script even when you have all ready untainted it in a subroutine.


The post_unco_trig is another trigger of interest as it needs to interact with other triggers. Since we want to prune uninteresting branch 0 versions on an uncheck out operation. Currently it sets an environment variable which the other triggers check. Version 3.2.1 of ClearCase appears to have a new environment variable CLEARCASE_POP_KIND which may provide the trigger interaction flag need. This environment variable was used in the pre_ln_trig trigger as it gets fired on a mkelem or mkdir operation before the pre_mkelem_trig trigger gets invoked. This trigger insures that there are no leaf branch connected to this branch 0 version, just in case the branch policy is changed to allow nested branches. It also checks for any labels just in case the labeling policy is changed. If it finds a label it will move it to the predecessor element since that is where the real version is anyway.


Will not allow any branch to be removed that has labels, leaf branches with none zero versions, or hlinks. If any of these conditions exist you must first remove them before this trigger will allow you to remove the branch.


Logs all checkins to the file process/checkin_logs/logfile. The report utilities are run by cron to email this log and convert it to an HTML file. It also removes the Cross_CKD attribute from a file checked in on a branch with the "bugs" string in the branch name.

Triggers and Authorization Lists

As stated above, the triggers are setup for fine grained Configuration Management control based on a set of attribute lists attached to the root of a VOB. Operations are not restricted for the owner of a VOB or the system root user. All other users are granted permission via the authorization control lists.

For Example: (CHECKIN_AUL="main:None;other:AllUsers;") says that no one is allowed to check in on the main branch and all users can check into any other branch. The attribute authorization lists are created and attached to the VOB object when you run the InstallAuthLists utility described in the section "Steps For Setting Up a New VOB".

Here is a fragment of the AuthLists file in the /home/ClearCase/process/config directory:

CHECKIN main "None"
CHECKIN other "AllUsers"
CHECKOUT all "AllUsers"
CHTYPE all "None"

We can see from this file fragment how the CHECKIN_AUL attribute was created by appending the the second and third fields of this file together with a ";" separator. The first field signifies which ClearCase operation this record applies to. The second field is the scoping filed and can have values like; all, other, lbtype, brtype, or attr. The third field has values like; None, AllUsers, comma separated list of users.

Working with the attribute lists

  1. ct setview
  2. cd VobTag
  3. ct describe -fmt %[CHECKIN_AUL]a vob:VobTag
    Will display the check in authorization attribute on a UNIX system. We still need to discover how to do this on an NT system.
  4. ct mkattr -rep CHTYPE_AUL '"all:None;"' vob:VobTag
    Will replace the value of the attribute CHTYPE_AUL.

Branching Policies

The Branch naming convention is one or more digits followed by lower case [a-z] letter. Branching is restricted to one level off of the main branch, see diagram below:

Branch Policies Diagram

A branch with the string "bugs" in it is treated as a restricted branch. If a reserved check out is done on this branch an attribute, Cross_CKD, will be attached to the file with a value of "FALSE". A user will not be able to check this file in until the attributes value is changed to "TRUE". The philosophy here is your probably modifying released software and we all know that fixing software many times causes new problems. After the file is checked in the attribute will be removed from the file.

This branching style was created with the concept that each branch would be a new product "feature" or "change set". The main branch would remain unchanged between releases and all release integration and testing would be done on a branch. After testing determines that the software is stable and ready for release a merge would be done from the integration branch to the main and a final test would be performed. This branching and control methodology has been used to do software development for FAA software certification.

The branch naming convention is implemented in a perl subroutine. Normally branch type creation would be restricted to development leads. When you create a new branch type you are prompted for a list of users to lock the branch to and a configuration specification rule file will be created for you. Branch names are checked to see if they meet your predefined rules and an example will be given the branch does not comply.

Labeling Policies

There are a few labeling rules supplied as examples of what can be done. The labeling policy subroutine will validate whether a label matches the rules you have chosen. If not an example of a correct label will be given. If a label is applied to a zero element on a branch a search will be done by the post make label trigger. It will move the label to the first non zero predecessor or remove it if none is found before the main zero version.

Mail Notification

We have supplied three different command line mail notification subroutines for different NT mailers; Postie, Blat, or Perl. For UNIX we use the mailx mailer. Two of the triggers pre_co_trig.bat and pre_mkbranch_trig.bat have commented out require statements and calls to the mail notification subroutine. The subroutines have URLs in the notes statement for the location to get the mailer. Pick the mailer you want to use. Rename the subroutine in the com directory to NotifyCMAdmin.pl. Finally uncomment the sections in the two triggers. If you choose to use the perl Sendmail module then you will also need to edit the shell and bat wrappers for the triggers.

Top of Page