Learn how to administer the product.
Learn to configure and manage the DevOps Code ClearCase® MultiSite and Rational® ClearQuest® MultiSite environments to support development activities at different locations.
To support development of VOB elements that cannot be merged, you can give developers the ability to request mastership of branches and branch types.
This is an example of serial development using requests for mastership.
Learn about performing administrative tasks for a DevOps Code ClearCase® community including managing software licenses, user and group accounts, ClearCase server and client hosts, shared data, and the network that connects them.
Learn how to perform DevOps Code ClearCase® administrative tasks on supported platforms.
DevOps Code ClearCase® MultiSite and add a powerful capability to DevOps Code ClearCase and . With MultiSite, developers at different locations can use the same DevOps Code ClearCase versioned object base (VOB) or . For DevOps Code ClearCase, each location (site) has its own copy (replica) of the VOB. At any time, changes made in one replica can be sent in update packets to other replicas. You can manage replicas by using the command-line tools.
Before you install and use DevOps Code ClearCase® MultiSite, you need to plan your implementation.
This section summarizes the commands for DevOps ClearCase® MultiSite and DevOps ClearCase that display DevOps Code ClearCase MultiSite information.
The method you choose for transporting packets between replicas depends on connectivity. If your replicas do not have IP connectivity, you must use a file-based transport method. If your replicas have connectivity, you can use the store-and-forward facility.
Feature levels allow different replica hosts in a VOB family to run different versions of DevOps Code ClearCase®. You can raise the feature level of either a single replica host or an entire VOB family.
Before creating a replica, you must make decisions about branching, mastership, identities and permissions preservation, and method of packet delivery.
Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
When a developer requests mastership of a branch, the branch's mastership is transferred to the developer's current replica. When a developer requests mastership of a branch type, mastership of the branch type, along with mastership of all the instances of the branch type that have default mastership, is transferred to the developer's current replica.
In order to enable requests for mastership in one or more replicas and for those requests to be handled efficiently, specific conditions must be met.
Before enabling requests for mastership, the project managers and administrators at the different sites must make specific planning decisions about whether requests for mastership are allowed for specific replicas, branches, and branch types, and which developers are authorized to make requests for mastership.
To enable requests for mastership for the replicas in a VOB family, you must verify the feature level, add developers to the access control list, specify any objects for which you want to deny requests, and then enable requests at the replica level for each replica in the VOB family.
Synchronous request for mastership (SRFM) means that a request for mastership of a branch is issued synchronously with a checkout of that remotely mastered branch, providing a writable branch before branch mastership is acquired.
After a mastership request is processed at the master replica, sync_export_list is invoked to export an update packet to the replica at the requester's site. You can customize the export by specifying one or more of the options and arguments that are valid for sync_export_list, except for –replicas, which is always the replica at the requester's site.
To display the mastership request setting for a replica, branch type, or branch, use the describe command or the Mastership page in the Properties Browser (Windows®). These settings are also displayed in the Request Mastership Window on Windows.
MultiSite provides commands you can use to troubleshoot failed mastership requests. When a request fails, the error messages provide an indication of what happened and what can be done to fix the problem.
In the serial development example, the company PurpleDoc develops documentation at three sites, using two VOB families.
Based on decisions made by administrators and project managers, the MultiSite administrators at each site configure access control for their site.
Each location has rules for creating site-specific branches in /vobs/html and selecting the latest version on that branch. The /main/LATEST rule is used in all the config specs for development in /vobs/doc and all other VOBs.
This scenario provides examples of how the writers use mastership requests to do their work.
You can use DevOps Code ClearCase® MultiSite to back up a VOB and to provide access to VOBs in a heterogeneous network.
When you encounter a situation where running a DevOps Code ClearCase® MultiSite command produces an unexpected result, or produces a warning or error message, the information in this section can assist you in troubleshooting the problem.