ClearCase Unified Change Management Triggers

[see other ClearCasePages on this CMWiki]

---

These triggers are designed to work in ClearCase 4.2 ClearCase 2002.05, and ClearCase 2003.06. They are operational at my site in Windows 2000, Windows XP, Red Hat Linux 8.0, and Solaris 2.8.

Currently, all triggers on this page were written in Perl, and will work with Perl 5.6.1, Perl 5.8, ClearCase's ccperl 5.001m on Windows, and ClearCase's Perl 5.002 on Unix-like platforms. I am personally moving my site to a networked installation of Perl for triggers as recommended by David Boyce in http://www.cleartool.com. I will note when ClearCase's ccperl and Perl will not suffice for any trigger scripts I post.

Some of these triggers resemble those documented in the ClearCase Administrator's manual. I think they are an improvement, especially since they can be enabled or disabled by the use of attributes on stream or project objects.

-- DavidBaird - 15 Dec 2003

UCM_BLOCK_DEVSTREAM

Prevents developers from creating development streams in a project: ucm_block_devstream.pl

This trigger is activated by setting a block_devstream attribute on the project object.

In ClearCase 2003.06, single-stream projects are supported. However, you cannot convert a single-stream project to a multi-stream project. You may want to use this trigger since you can convert to a multi-stream project simply by removing the block_devstream attribute. Furthermore, the ClearCase Web interface doesn't support single-stream projects. This trigger does work with the web interface.

The purpose of this trigger is to allow for projects with only an integration stream. This is useful for document type files like Rose, Word, and Excel, where merging is either impossible or difficult to operate. The tools controlling the documents often have utilities to facilitate parallel development on a single stream.

UCM_BLOCK_ACTIVITY

Prevents developers from creating non-delivery and non-rebase activities on integration streams, and from reusing delivery and rebase activities: ucm_block_activity.pl

This trigger is supported by two attributes on a stream object.

• integrators: a space separated list of users whom can circumvent this trigger for a particular stream
• unblocked: disables this trigger completely for a particular stream
• readonly: designate a read only stream while allowing rebase to any baseline

The objective of this trigger is to prevent improper usage of the deliver and rebase activities, and improper use of the integration streams. Without this trigger, users are susceptible to erroneous usage of an integration view, especially if they forgot which view is attached to which drive on Windows. It also forces users to create a new activity or reuse an old non-rebase activity on their development streams.

In ClearCase 2003.06, read only streams are supported. However, you cannot convert a read only stream to a modifiable stream or visa versa. Furthermore, you cannot change the baseline of a read only stream on a ClearCase 2002.05 client. With this trigger and the readonly attribute on any stream, you can do all these things.

UCM_SERIAL_DELIVERY

Implement a development policy that eliminates the confusion that concurrent deliveries or rebases can cause developers. Only one developer can deliver to an integration stream at a time: ucm_serial_delivery.pl

This trigger also prevents a delivery from a development stream to another project's integration stream.

UCM_COMPLETE_DELIVERY

A shopping list of operations upon completion of a delivery or rebase in an integration stream: ucm_complete_delivery.pl

All operations are enabled by attributes on the integration stream:

• auto_baseline_name: create a baseline automatically based on a pattern.
• auto_baseline_email: send an email report to the specified email address. This depends on a baseline being automatically generated. Multiple address must be separated by commas.
• auto_baseline_diff: attach a difference report of changed directories and text files to the automated email message.
• deliver_to_stream: start a delivery of the new baseline to a different integration stream. This can be from a child integration stream to a project level integration stream or to another project's integration streams. The value is the name of the target integration stream.

The format of the baseline pattern value must be one of:

   BASELINE_xxx    ex: BL.11.22_xxx
   BASELINE*_xxx   ex: BL.11.*_xxx
   BASELINE.xxx    ex: BL.11.22.xxx
   BASELINE*.xxx   ex: BL.11.*.xxx

The number of x's allowed is variable, but it must be at the end of the baseline pattern and preceeded by an underline (_) or a period (.).

The purpose of the star (*) is to allow a numberic value as part of the pattern, which may vary. This allows a sequence for example of BL.11.01_001, BL.11.01_002, BL.11.01_003, ... Then you manually place a new baseline BL.11.02_000, and the sequence continues with BL.11.02_001, BL.11.02_002, BL.11.02_003, ...

You must place a first baseline on the integration stream, for example, BL.11.22_000.

UCM_CHECK_TARGETS

Checks a list of targets to see that they were built with all changed elements in a delivery activity: ucm_check_targets.pl

This trigger is enabled by an attribute check_targets, which either lists a number of build target files, or a path to a text file with a list of targets to check.

The purpose of this trigger is to verify that the mission critical build targets were built with the changes in the delivery. This requires that the build scripts are run with clearmake or omake. This trigger only warns the user, and allows him to continue with completing the delivery. In small development groups, where any engineer can deliver to the integration stream, this trigger validates some integrity of the integration stream.

---

Edit • Attach • Print version • History: r17 < r16 < r15 < r14 < r13 • Backlinks • Raw View • Raw edit • More topic actions