Using attributes, hyperlinks, triggers, and locks
Attributes are name/value pairs that allow you to capture information about the state of a version from various perspectives. For example, you can attach an attribute named CommentDensity to each version of a source file, to indicate how well the code is commented. Each such attribute can have the value unacceptable, low, medium, or high.
Hyperlinks allow you identify and preserve relationships between elements in one or more VOBs. This capability can be used to address process-control needs, such as requirements tracing, by allowing you to link a source file to a requirements document.
Triggers allow you to control the behavior of cleartool commands and HCL VersionVault operations by arranging for a specific program or executable script to run before or after the command executes. Virtually any operation that modifies an element can fire a trigger. Special environment variables make the relevant information available to the script or program that implements the procedure.
Preoperation triggers fire before the designated HCL VersionVault command is executed. A preoperation trigger on checkin can prompt the developer to add an appropriate comment. Postoperation triggers fire after a command has exited and can take advantage of the command’s exit status. For example, a postoperation trigger on the checkin command can send an e-mail message to the QA department, indicating that a particular developer modified a particular element.
- Applying attributes or attaching labels to objects when they are modified
- Logging information that is not included in the HCL VersionVault event records
- Initiating a build and/or source code analysis whenever particular objects are modified
A lock on an element or directory prevents all developers (except those included on an exception list) from modifying it. Locks are useful for implementing temporary restrictions. For example, during an integration period, a lock on a single object—the main branch type—prevents all users who are not on the integration team from making any changes.
The effect of a lock can be small or large. A lock can prevent any new development on a particular branch of a particular element; another lock can apply to the entire VOB, preventing developers from creating any new element of type compressed_file or using the version label RLS_1.3.
Locks can also be used to retire names, views, and VOBs that are no longer used. For this purpose, the locked objects can be tagged as obsolete, effectively making them invisible to most commands.