Before development work is started in any VOB, the project manager and administrator must define the ClearCase use model. For example, the project manager must specify the branches, labels, and triggers that are used for development and integration work. The following sections describe the ways in which MultiSite use affects this planning.
Mastership restrictions affect the choices you make about branching and merging:
Another approach is to use a single release integration branch, multiple site integration branches, and multiple developer branches. Developers or project managers at a replica merge to the site integration branch, and the project manager at the replica that masters the release integration branch merges to that branch from the site integration branches.
You may need to allow developers to transfer and request mastership of branches and branch types. Developers at different sites may have to use the same branch type (for example, because an element’s versions can’t be merged, or because each site must merge its own work to the integration branch). A branch or branch type’s mastership cannot be shared by multiple replicas; instead, there are two models for transferring mastership between replicas:
Model 1. Create a schedule that determines when each replica masters the branch or branch type. Create scripts to transfer mastership.
Model 2. Give the developers at the sites the ability to request mastership of the branch or branch type. For more information about this model, see Implementing Requests for Mastership.
Note: Do not use mastership transfer models as substitutes for good branching and merging rules. Enabling requests for mastership involves more planning and setup than implementing a strategy for branching and merging. Also, if you can develop in parallel, planned branching and merging is safer than allowing developers to request mastership and merge their own work randomly.
element * CHECKEDOUT element * .../v1.0_bugfix/LATEST element * .../v1.0/LATEST -mkbranch v1.0_bugfix element * /main/0 -mkbranch v1.0
You can assign mastership of a new element’s main branch and other branches created during element creation to your current replica. For more information, see Assigning Branch Mastership During Element Creation.
Mastership restrictions affect the way you use ClearCase attributes, labels, and hyperlinks. You need to decide whether these types must be shared. You can create instances of an unshared type only in the replica that masters it. You can create instances of a shared type only in the replica that masters the object to which you are attaching the instance, with additional restrictions if you are using global types. For more information, see Type Object Mastership.
Trigger types and triggers are not replicated. If a trigger is in use at one replica and needs to be used at other replicas, you must send the appropriate information (for example, the output of a describe trtype: command and the contents of any associated scripts) to the administrators at the other sites.
It is important to prevent two or more replicas of the same VOB from being mounted on the same host—one host can belong to only one region and each region can contain only one replica. Do not assign public VOB tags in the same ClearCase registry region to multiple replicas of the same VOB.
For information about how VOBs and VOB replicas are listed in the ClearCase storage registry, see VOB Objects and VOB Replica Objects. For information about using multiple replicas at one site, see Using MultiSite for VOB Backup and Interoperability.
When you create a new replica, it has the same text mode as the replica from which it was exported. However, changes to a replica’s text mode are not propagated to the other replicas in the family; so if you make a text mode change that needs to occur at all replicas in the family, you and the other MultiSite administrators must change the text mode at each replica. For more information about text modes, see the Administrator’s Guide for Rational ClearCase.
If replicated VOBs use global types, the administrative VOBs must be replicated. For more information about global types, see the Administrator’s Guide for Rational ClearCase.
Additional mastership restrictions exist when you use an administrative VOB hierarchy and its global types. If a global type is shared, you can create instances of the type in a replica only if one of the following conditions exists:
These restrictions apply even if your current replica masters the object to which you are attaching the instance. These restrictions prevent conflicting, simultaneous creation of a given type with a given name at multiple sites.
When you use ClearCase UCM and MultiSite, some developer and project manager tasks are different. A project’s integration stream is mastered by one of the replicas in the VOB family, and developers at other replicas must do a remote deliver of their work to the stream. The project manager at the master replica completes the deliver operations. The Developing Software and Managing Software Projects manuals describe this scenario in more detail.
The following restrictions apply to use of UCM and MultiSite: