2.3 ClearCase Use Model

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.

Branching and Mastership

Mastership restrictions affect the choices you make about branching and merging:

• A common branching strategy is to use a single release branch (or integration branch) and multiple development branches. The project manager or developer merges changes from the development branch to the integration branch. You can use this strategy with MultiSite, but the merges to the integration branch must occur at the replica that masters the integration branch.

You could also use a single release integration branch, multiple site integration branches, and multiple developer branches. With this scenario, 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 sites:

Model 1. Create a schedule that determines when each site 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 Chapter 9, 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.

• You can use auto-make-branch rules in config specs only if the current replica masters the branch type in the rule. For example, if your current replica masters the v1.0_bugfix branch type but not the v1.0 branch type, this config spec is incorrect because the v1.0 branch cannot be created at this replica:

element * CHECKEDOUT element * .../v1.0_bugfix/LATEST element * .../v1.0/LATEST -mkbranch v1.0_bugfix element * /main/LATEST -mkbranch v1.0




• By default, when you create an element in a replicated VOB, mastership of the branch main is assigned to the replica that masters the branch type main. If this replica is not your current replica, you cannot create new versions on the main branch. Also, if your config spec contains mkbranch rules and your current replica does not master the branch types, the branches cannot be created during element creation.

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.

Use of Metadata

Mastership restrictions affect the way you use ClearCase attributes, labels, or 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. 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.

Text Mode for Replicas

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.

Use of Administrative VOBs or UCM

If replicated VOBs use global types, the administrative VOBs must be replicated. For more information on global types, see the Administrator's Guide for Rational ClearCase.

NOTE: If a global type is shared, Rational ClearCase can create a local copy of the type only if the type is mastered by the administrative VOB replica at the current site. If the shared global type is not mastered at the current site, you can create instances of the type only if the client VOB replica contains a local copy of the type. This restriction applies even if your current replica masters the object to which you are attaching the instance. This mastership restriction prevents conflicting, simultaneous creation of a given type with a given name at multiple sites. For more information, see Administrator's Guide for Rational ClearCase.

If you replicate a component VOB, you must replicate its PVOB.

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.