To enable requests for mastership in one or more replicas, the following conditions must apply:
The VOB family is at feature level 2 or higher. (All replicas in the VOB family must be at feature level 2 or higher, even if you are not going to enable requests in all of the replicas.) For more information on feature levels, see Chapter 5, ClearCase Feature Levels.
The sites have high-speed connections (LAN, WAN, T1).
A request for mastership makes RPCs directly to remote servers and fails if the sites are not connected. If a site has a firewall, developers at that site cannot request mastership from replicas at other sites, and developers at other sites cannot request mastership of any branches mastered at a site with a firewall.
Each replica masters its own replica object. These replicas are called self-mastering.
If a replica does not master its own replica object, you cannot enable or disable mastership requests at the replica level. For information about reassigning mastership of the replica object, see Transferring Mastership of a Replica Object.
For mastership requests to work efficiently, the following conditions must apply:
There is no contention for branches or branch types among the sites. That is, only one person at a time requests mastership of a branch or branch type.
If two or more developers at different sites compete for mastership of objects, mastership will always be in flux. In this situation, the project leaders and MultiSite administrators must determine whether the branch sharing strategy needs to be changed. Using requests for mastership is not a substitute for using good branching and merging practices.
The sites exchange update packets frequently.
Each replica needs current information about object mastership. If a replica is not up to date, requests for mastership from that site cannot determine which replica masters the requested object. Also, if replicas exchange packets infrequently, a mastership request may cause the generation of a large update packet, which will take longer to generate and import.)
Each replica host uses a receipt handler to import packets.
You can schedule scripts to import packets regularly. However, to import a packet as soon as it arrives at the replica host, you must use a receipt handler. For more information, see the shipping.conf (UNIX) or MultiSite Control Panel (Windows) reference page.
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |