When you create an object in a replicated VOB, your current replica is the new object’s master replica. To transfer mastership of the object to another replica, use the chmaster command or the Properties Browser (Windows). Some examples of when this is appropriate:
Mastership changes are communicated among replicas by the standard synchronization mechanism. The general procedure for changing mastership is as follows:
Until the update packet containing the mastership change is imported at the new master replica, mastership is “in the packet” and the replicas in the VOB family have different information about which replica masters the object.
For example, the administrator at the sanfran_hub replica transfers mastership of the bugfix branch to the bangalore replica, and then exports an update packet. At this point, before the packet is imported at the bangalore replica:
When you complete the mastership transfer by importing the update packet at bangalore, developers at bangalore are able to create new versions on the branch.
Notes on mastership changes:
The following sections describe how to change mastership of objects. These procedures use the command line. For information about using the Properties Browser on Windows to transfer mastership of a ClearCase object, see the MultiSite Help.
When you create a type object, it is mastered by the replica where you create it. Except for elements, instances of an unshared type can be created only at the master replica. Elements can be created at any replica, regardless of which replica masters the element type. Instances of shared types can be created at any replica if the replica masters the target object. (For more information, see Type Object Mastership; there are additional restrictions if the type is a global type.)
Note: If you change mastership of a branch type to another replica, mastership is not changed for explicitly mastered branches of that type, even if the same replica masters the branch type and the branch. Mastership is changed for branches of that type with default mastership. To change explicitly mastered branches to have default mastership, see Removing Explicit Mastership of a Branch.
To transfer mastership of a type object:
multitool describe lbtype:TOKYO_BASE@/vobs/dev label type "TOKYO_BASE" created 15-Aug-00.14:20:26 by Susan Goechs (susan.user@minuteman) master replica: boston_hub@/vobs/dev ...
MINUTEMAN% multitool chmaster –c "transfer to sanfran_hub" sanfran_hub@/vobs/dev lbtype:TOKYO_BASE@/vobs/dev Changed mastership of label type "TOKYO_BASE" to "sanfran_hub@/vobs/dev"
MINUTEMAN% multitool syncreplica –export –fship sanfran_hub@/vobs/dev Generating synchronization packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_2 6-Aug-02.18.15.57_7430_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_sync_boston_ hub_26-Aug-02.18.15.57_7430_1 Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_2 6-Aug-02.18.15.57_7430_1
BAGUETTE% multitool syncreplica –import –receive Applied sync. packet /opt/rational/clearcase/shipping/ms_ship/incoming/sync_boston_hub_2 6-Aug-02.18.15.57_7430_1 to VOB /net/goldengate/vobstg/dev.vbs
BAGUETTE% multitool describe lbtype:TOKYO_BASE@/vobs/dev label type "TOKYO_BASE" created 15-Aug-02.14:20:26 by Susan Goechs (susan.user@minuteman) master replica: sanfran_hub@/vobs/dev ...
When you create a new replica, its replica object is mastered by the replica at which you enter the mkreplica –export command. Mastership of the replica object affects replica-modification activities (renaming the replica, changing its properties, or deleting it). You must perform these activities at the replica that masters the replica object.
A self-mastering replica masters its own replica object. A replica must be self-mastering for you to perform some administrative operations on it (for example, raising the feature level). If each site has its own administrator for Rational ClearCase MultiSite, self-mastering replicas simplify replica maintenance because each one can be maintained at its own site. However, you may want to master all replica objects at a hub replica. In this case, you can transfer mastership to individual sites at the request of the site administrator, and transfer mastership back to the hub replica after the administrative operation has been completed.
To transfer mastership of a replica object:
multitool describe replica:sanfran_hub@/vobs/dev replica "sanfran_hub" created 16-Aug-00.09:49:36 by Susan Goechs (susan.user@minuteman) replica type: unfiltered master replica: boston_hub@/vobs/dev owner: susan group: user host: "goldengate" ...
MINUTEMAN% multitool chmaster –c "make sanfran_hub replica self-mastering" sanfran_hub@/vobs/dev replica:sanfran_hub@/vobs/dev Changed mastership of replica "sanfran_hub" to "sanfran_hub@/vobs/dev"
MINUTEMAN% multitool syncreplica –export –fship sanfran_hub@/vobs/dev Generating synchronization packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_1 6-Aug-00.16.15.57_6389_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_sync_boston_ hub_16-Aug-00.16.15.57_6389_1 Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_1 6-Aug-00.16.15.57_6389_1
GOLDENGATE% multitool syncreplica –import –receive Applied sync. packet /opt/rational/clearcase/shipping/ms_ship/incoming/sync_boston_hub_1 6-Aug-00.16.15.57_6389_1 to VOB /net/goldengate/vobstg/dev.vbs
GOLDENGATE% multitool describe replica:sanfran_hub@/vobs/dev replica "sanfran_hub" created 16-Aug-00.09:49:36 by Susan Goechs (susan.user@minuteman) replica type: unfiltered master replica: sanfran_hub@/vobs/dev ...
When you replicate a VOB for the first time, the VOB is mastered by the original replica. If you need to lock the VOB with the obsolete option, you must do it at the VOB’s master replica.
To transfer mastership of a VOB to another replica, follow these steps:
MINUTEMAN% multitool chmaster sanfran_hub vob:/vobs/dev Changed mastership of versioned object base "/vobs/dev" to "sanfran_hub".
MINUTEMAN% multitool syncreplica –export –fship sanfran_hub@/vobs/dev Generating synchronization packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_2 0-Sep-02.17.35.45_22513_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_sync_boston_ hub_20-Sep-02.17.35.45_22513_1 Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_2 0-Sep-02.17.35.45_22513_1
GOLDENGATE% multitool syncreplica –import –receive Applied sync. packet /opt/rational/clearcase/shipping/ms_ship/incoming/sync_boston_hub_2 0-Sep-02.17.35.45_22513_1 to VOB /net/goldengate/vobstg/dev.vbs
GOLDENGATE% multitool describe –fmt "%n\t%[master]p\n" vob:/vobs/dev /vobs/dev sanfran_hub@/vobs/dev
When you create a new element, it is mastered by the replica in which you create it. You must perform the following element operations at the element’s master replica:
To transfer mastership of an element to another replica:
MINUTEMAN% multitool chmaster bangalore tests.txt@@ Changed mastership of file element "tests.txt@@" to "bangalore"
MINUTEMAN% multitool syncreplica –export –fship bangalore@/vobs/dev Generating synchronization packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_0 7-Dec-02.18.15.57_5978_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_sync_boston_ hub_07-Dec-02.18.15.57_5978_1 Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_0 7-Dec-02.18.15.57_5978_1
RAMOHALLI> multitool syncreplica –import –receive Applied sync. packet C:\Program Files\Rational\ClearCase\var\shipping\ms_ship\incoming\sync_boston_ hub_07-Dec-02.18.15.57_5978_1 to VOB \\ramohalli\vobs\dev.vbs
RAMOHALLI> multitool describe –fmt "%n\t%[master]p\n" tests.txt@@ tests.txt@@ bangalore@\dev
This section describes how to change mastership of a branch using the chmaster command. For information about enabling use of the reqmaster command, see Implementing Requests for Mastership.
To transfer mastership of a branch to another replica:
MINUTEMAN% multitool chmaster –c "bugfix at bangalore" bangalore Makefile@@/main Changed mastership of branch "Makefile@@/main" to "bangalore"
MINUTEMAN% multitool syncreplica –export –fship bangalore@/vobs/dev Generating synchronization packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_1 0-Dec-02.18.15.57_3056_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_sync_boston_ hub_10-Dec-02.18.15.57_3056_1 Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_boston_hub_1 0-Dec-02.18.15.57_3056_1
RAMOHALLI> multitool syncreplica –import –receive Applied sync. packet C:\Program Files\Rational\ClearCase\var\shipping \ms_ship\incoming\sync_boston_hub_10-Dec-02.18.15.57_3056_1 to VOB \\ramohalli\vobs\dev.vbs
RAMOHALLI> multitool describe –fmt "%n\t%[master]p\n" Makefile@@\main Makefile@@\main bangalore@\dev
As described in Default and Explicit Branch Mastership, a branch can have default or explicit mastership. After you follow the steps in Transferring Branch Mastership, the branch has explicit mastership. When you transfer mastership of a branch type to another replica, mastership is transferred for all branches with default mastership, but not for branches with explicit mastership.
To return mastership of a branch to the replica that masters the branch type:
RAMOHALLI> multitool chmaster –default Makefile@@\main Changed mastership of branch "Makefile@@\main" to "default"
RAMOHALLI> multitool describe –fmt "%n\t%[master]p\n" brtype:main main boston_hub@\dev
If your current replica masters the branch type, stop here. If another replica masters the branch type, continue with Step 3.
RAMOHALLI> multitool syncreplica –export –fship boston_hub@\dev Generating synchronization packet C:\Program Files\Rational\ClearCase\var\shipping\ms_ship\outgoing\sync_bangalo re_11-Dec-02.18.15.57_9476_1 - shipping order file is /opt/rational/clearcase/shipping/ms_ship/outgoing/sh_o_sync_bangalo re_11-Dec-02.18.15.57_9476_1 Attempting to forward/deliver generated packets... -- Forwarded/delivered packet /opt/rational/clearcase/shipping/ms_ship/outgoing/sync_bangalore_11 -Dec-02.18.15.57_9476_1
MINUTEMAN% multitool syncreplica –import –receive Applied sync. packet /opt/rational/clearcase/shipping/ms_ship/incoming/sync_bangalore_11 -Dec-02.18.15.57_9476_1 to VOB /net/minuteman/vobstg/dev.vbs
MINUTEMAN% multitool describe Makefile@@/main branch "Makefile@@/main" created 27-Aug-00.13:41:21 by Gail Smith (gail.user@boston20) branch type: main master replica: boston_hub@/vobs/dev (defaulted)
The other form of the chmaster –default command applies to branches that are explicitly mastered by the replica that masters the branch type. To give these branches default mastership, enter a chmaster –default command and specify the branch type:
MINUTEMAN% multitool chmaster –default brtype:main Changed mastership of branch type "main" to "default"
The chmaster –stream command transfers mastership of a stream and its associated objects. For example, to transfer mastership of the stream v2.1.bl5 and its associated objects to the boston_hub replica:
In some cases, you must manually change mastership of branch types or activities associated with a stream. The output of the chmaster command includes a list of these objects. The output may also include an instruction to run the chmaster –stream command with the –override option. This option transfers mastership of objects whose mastership was not transferred during the original invocation of the command.
Caution: Do not use –override unless the output of chmaster –stream indicates that you should do so.
Before removing a replica, you must transfer mastership of all objects mastered by that replica. For instructions, see Deleting a Replica.
The following example shows a partially successful chmaster –all command and describes how to fix it. In this example, the administrator at replica bangalore is transferring mastership to boston_hub.
RAMOHALLI> multitool chmaster –all –long boston_hub@\dev Changed mastership of versioned object base \dev\ Changed mastership of directory element \dev\.@@ Changed mastership of directory element \dev\lost+found@@ ... multitool: Error: Branch type "bangalore_main" has branches (with default mastership) that have outstanding checkouts. Changed mastership of branch type v1.0_bugfix ... multitool: Error: Lock on label type "V1.0_BUGFIX" prevents operation "change master". Changed mastership of label type BANGALORE_V2.0 ... Changed mastership of replica bangalore multitool: Warning: Not all objects had mastership changed.
These errors prevent the successful completion of this chmaster command:
To fix these problems:
H:\dev> cleartool lscheckout –all 03-Jun.17:28 jk checkout version "\dev\cmdsyn.c" from \main\bangalore_main\83 (unreserved) 08-Jun.12:45 singh checkout version "\dev\etc\util\tool.c" from \main\bangalore_main\22 (unreserved) ...
See the checkin, checkout, and uncheckout reference pages.
cleartool unlock lbtype:V1.0_BUGFIX@\dev Unlocked label type "V1.0_BUGFIX".
Alternatively, enter a lock –replace –nusers command and add yourself to the –nusers list.
cleartool lock –replace –nusers ms_admin lbtype:V1.0_BUGFIX@\dev Locked label type "V1.0_BUGFIX".
RAMOHALLI> multitool chmaster –all –long boston_hub@\dev Changed mastership of branch type bangalore_main Changed mastership of label type V1.0_BUGFIX Changed mastership of all objects.