3.8 How MultiSite Affects the UCM-ClearQuest Integration

If you use MultiSite to replicate the PVOB or ClearQuest user database involved in the UCM-ClearQuest integration, you need to be aware of several requirements. This section describes those requirements.

Replica and Naming Requirements

When you set up the UCM-ClearQuest integration, you establish a link between a PVOB and a ClearQuest user database. If you use MultiSite, the following requirements apply:

Enabling a Project to Use the UCM-ClearQuest Integration

This section describes the additional steps to set up the UCM-ClearQuest integration when you use MultiSite. For the full set of steps required to enable a project to work with ClearQuest, see the Setting Up the Project chapter in Managing Software Projects with ClearCase.

Transferring Mastership of the PVOB's Root Folder

The first time you enable a project within a PVOB to work with ClearQuest, your current PVOB replica must master the PVOB's root folder. If your current replica does not have mastership, transfer mastership of the root folder by using the multitool chmaster command at the replica that masters the root folder. The following example transfers mastership of the root folder from the current replica to the lowell replica.

multitool chmaster lowell folder:RootFolder

See ClearCase MultiSite Manual for details on transferring mastership.

Transferring Mastership of the Project

Before you enable a project to work with ClearQuest, your current PVOB replica must master the project. If your replica does not master the project, transfer mastership of the project by using the multitool chmaster command at the replica that masters the project.

When you enable the project to work with ClearQuest, the integration creates a corresponding project record in the ClearQuest user database and assigns mastership of that record to the current replica of the ClearQuest user database. If a project record with the same name as the project exists in the ClearQuest user database when you enable the project, and that project record is not mastered by your current replica, you must transfer mastership of the project record to your current replica.

Linking Activities to ClearQuest Records

If a project contains activities, when you enable that project to work with ClearQuest, the integration creates corresponding ClearQuest records for the activities and links the records to the activities. The integration cannot link activities that are mastered by remote replicas. To link activities that are mastered by a remote replica:

  1. At the remote site, start ClearCase Project Explorer. On UNIX, enter clearprojexp. On Windows, in the left pane of ClearCase Explorer, click UCM, and then click Project Explorer.

  2. In the Project Explorer, display the project's property sheet, and click the ClearQuest tab.

  3. Click Ensure all Activities are Linked. The integration checks all the project's activities. If the project is enabled, the integration links any unlinked activities. The integration then displays the following summary information:

  4. At each replica on the list described in Step #3, repeat Step #1 through Step #3.

Managing the Project

This section describes how MultiSite affects how you maintain the project after enabling it to work with ClearQuest.

Changing Project Policy Settings

Before you can change a project's policy settings from within ClearQuest, the ClearQuest project record must be mastered. Similarly, before you can change a project's policy settings from within ClearCase, the project object must be mastered. After you change a project's policy settings in the current replica, the new settings do not take effect in streams in sibling replicas until you synchronize the current replica with those replicas. See ClearCase MultiSite Manual for details on synchronizing replicas.

Controlling Deliver Operations

The Do ClearQuest Action After Delivery project policy transitions activities to a Complete type state when a deliver operation completes successfully. For this policy to work correctly in a MultiSite environment, the activities being delivered must be mastered by the same replica that masters the target integration stream. To ensure that this is the case, you can set the Check Mastership Before Delivery policy.

The behavior of the Check Mastership Before Delivery policy depends on whether the deliver operation is local or remote. If the deliver operation is local, meaning that the target integration stream is mastered by the local PVOB replica, this policy causes the deliver operation to fail unless all activities being delivered are mastered locally.

A remote deliver operation is one for which the target integration stream is mastered by a remote PVOB replica. The developer starts the deliver operation but ClearCase leaves the operation in a posted state. The project manager at the remote site completes the deliver operation.

For a remote deliver operation, the Check Mastership Before Delivery policy causes the following behavior:

Changing the Project Name

The integration links a project name to the title field in the corresponding ClearQuest project record. If you change the project name in ClearCase, the integration makes the same change to the title field in the corresponding ClearQuest project record. Similarly, if you change the title in ClearQuest, the integration makes the same change to the project name in ClearCase. Before you can change the project name and title in a MultiSite environment, the project record and the project object must both be mastered.

Working on Activities

Before you can work on, set, or change an activity, the activity object and its ClearQuest record must be mastered locally.