There are two similar, but separate facilities that integrate AccuRev's configuration management functionality with its issue management (AccuWork) functionality. The one described in this topic a particular issue-record field as the point of integration. The other (
Change-Package-Level Integration between AccuRev and AccuWork on page 326) uses change packages as the point of integration. Both integrations record information about the
Promote transaction in a user-specified AccuWork issue record.
The integration between configuration management and issue management at the transaction level records the number of each
promote transaction in a particular field of a user-specified issue record.
Note that "client_dispatch_promote" is simply a keyword, not the name of a script file. The integration is implemented by two cooperating routines, one built into the AccuRev client software, one built into the AccuRev server software.
If the user enters "0" or makes a blank entry, the Promote command completes but no change is made to any issue record. This provides a way for the user to bypass the integration.
Over time, the affectedFiles field of a given issue record can accumulate a
SPACE-separated list of
Promote transaction numbers.
You enable the integration by setting the pre-promote-trig trigger with the "client_dispatch_promote" keyword, as described above. You don't need to explicitly set a
server-post-promote-trig trigger script. If you do, the script runs instead of -- not in addition to -- the server-side built-in routine.
In most cases, you'll want to avoid setting a server-post-promote-trig trigger script, just letting the built-in routines do their work. But suppose that after a
Promote , you want the server machine to perform operations in addition to those defined in the transaction-level integration -- for example, updating reference trees and sending email messages. In such cases:
Further customizations of the transaction-level integration are possible. For example, you might want the user to be able to specify several issue records, not just one. Or you might want to link
promote commands in one depot with the AccuWork issues database in another depot. Or you might want to update an issue record field other than
affectedFiles. In such cases, you'll want to dispense with the built-in "client_dispatch_promote" routines altogether:
Both the change-package-level and transaction-level integrations can be enabled for a given depot at the same time. In this case, a user performing a
Promote command in a workspace is prompted to specify an issue record just once, not twice. The prompting for an issue record by the change-package-level integration takes place as usual. That issue record is then updated by both integrations.
Note that even if both integrations are enabled, a Promote command performed in a dynamic stream (not a workspace) activates just the transaction-level integration, not the change-package-level integration.