|
|
When you create an object in a replicated VOB, your current replica is the new object's master. You can transfer mastership of the object to another replica, using the chmaster command or the Properties Browser (Windows). Some examples of when this is appropriate:
If responsibility for product integration is shifted to a different site, you must transfer mastership of the integration branch types or branches to the new site.
Before you decommission a replica, you must transfer mastership of each object mastered by that replica to one of the remaining replicas. (See Deleting a Replica.)
Mastership changes are communicated among replicas by the standard synchronization mechanism. The general procedure for changing mastership is as follows:
Change mastership of one or more objects to another replica or request mastership of a branch or branch type.
Export and send an update packet from the old master replica to the new master replica. (The reqmaster command does this automatically.)
Import the update packet at the new master replica.
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:
The sanfran_hub replica considers the branch to be mastered by bangalore.
The bangalore replica considers the branch to be mastered by sanfran_hub.
No one can create new versions on the branch.
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.
The chmaster command requires a view context.
If your VOB family includes any read-only or one-way replicas (replicas that import update packets but do not export them), be careful about transferring mastership to these replicas. After you give mastership of an object to a read-only or one-way replica, you cannot change the object's mastership again unless you change the VOB family's synchronization pattern.
You cannot undo a mastership change made at your site by making the opposite change at your site. See Fixing an Accidental Mastership Change.
You can use triggers to prevent developers from changing mastership of objects. For more information, see Implementing Project Development Policies in Managing Software Projects.
The following sections describe how to change mastership of ClearCase 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 online help:
Click Start > Programs > Rational ClearCase Administration > MultiSite Help.
On the Contents tab of the Help Contents Window, click Administrator Tasks > To change mastership of a ClearCase object.
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 (for more information, see Type Object Mastership).
NOTE: If you transfer mastership of a branch type to another replica, mastership of explicitly mastered branches of that type is not transferred, even if the same replica masters the branch type and the branch. To give such branches default mastership, see the procedure in Removing Explicit Mastership of a Branch.
To transfer mastership of a type object:
Determine which replica masters the 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
...
At the master replica, enter a chmaster command:
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"
At the old master replica, export an update packet to the new master replica's site:
MINUTEMAN% multitool syncreplica -export -fship sanfran_hub@/vobs/dev
Generating synchronization packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_26-Aug-00.18.15.57_74
30_1
- shipping order file is
/usr/atria/shipping/ms_ship/outgoing/sh_o_sync_boston_hub_26-Aug-00.18.15.
57_7430_1
Attempting to forward/deliver generated packets...
-- Forwarded/delivered packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_26-Aug-00.18.15.57_74
30_1
At the new master replica, import the packet:
BAGUETTE% multitool syncreplica -import -receive
Applied sync. packet
/usr/atria/shipping/ms_ship/incoming/sync_boston_hub_26-Aug-00.18.15.57_74
30_1 to VOB /net/goldengate/vobstg/dev.vbs
At the new master replica, verify that mastership has been received:
BAGUETTE% 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: 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 MultiSite administrator, having self-mastering replicas simplifies replica maintenance because each replica 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 then transfer mastership back to the hub replica after the administrative operation has been completed.
To transfer mastership of a replica object:
Determine which replica masters the replica object, and the host name of the replica's VOB server:
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"
...
At the master replica, enter a chmaster command:
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"
At the old master replica, export an update packet to the new master replica:
MINUTEMAN% multitool syncreplica -export -fship sanfran_hub@/vobs/dev
Generating synchronization packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_16-Aug-00.16.15.57_63
89_1
- shipping order file is
/usr/atria/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
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_16-Aug-00.16.15.57_63
89_1
At the new master replica, import the packet:
GOLDENGATE% multitool syncreplica -import -receive
Applied sync. packet
/usr/atria/shipping/ms_ship/incoming/sync_boston_hub_16-Aug-00.16.15.57_63
89_1 to VOB /net/goldengate/vobstg/dev.vbs
At the new master replica, verify that mastership has been received:
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. You must perform the following operations at the VOB's master replica:
Changing protections on the VOB (for ownership-preserving replicas).
Locking the VOB with the obsolete option.
To transfer mastership of a VOB to another replica, follow these steps:
At the master replica, enter a chmaster command:
MINUTEMAN% multitool chmaster sanfran_hub vob:/vobs/dev
Changed mastership of versioned object base "/vobs/dev" to "sanfran_hub".
At the old master replica, export an update packet to the new master replica's site:
MINUTEMAN% multitool syncreplica -export -fship sanfran_hub@/vobs/dev
Generating synchronization packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_20-Sep-00.17.35.45_22
513_1
- shipping order file is
/usr/atria/shipping/ms_ship/outgoing/sh_o_sync_boston_hub_20-Sep-00.17.35.
45_22513_1
Attempting to forward/deliver generated packets...
-- Forwarded/delivered packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_20-Sep-00.17.35.45_22
513_1
At the new master replica, import the packet:
GOLDENGATE% multitool syncreplica -import -receive
Applied sync. packet
/usr/atria/shipping/ms_ship/incoming/sync_boston_hub_20-Sep-00.17.35.45_22
513_1 to VOB /net/goldengate/vobstg/dev.vbs
At the new master replica, verify that mastership has been received:
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:
Changing protections on the element (for ownership-preserving replicas).
Locking the element with the obsolete option.
Removing the element.
To transfer mastership of an element to another replica, follow these steps:
At the master replica, enter a chmaster command:
MINUTEMAN% multitool chmaster bangalore tests.txt@@
Changed mastership of file element "tests.txt@@" to "bangalore"
At the old master replica, export an update packet to the new master replica's site:
MINUTEMAN% multitool syncreplica -export -fship bangalore@/vobs/dev
Generating synchronization packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_07-Dec-00.18.15.57_59
78_1
- shipping order file is
/usr/atria/shipping/ms_ship/outgoing/sh_o_sync_boston_hub_07-Dec-00.18.15.
57_5978_1
Attempting to forward/deliver generated packets...
-- Forwarded/delivered packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_07-Dec-00.18.15.57_59
78_1
At the new master replica, import the packet:
RAMOHALLI> multitool syncreplica -import -receive
Applied sync. packet C:\Program
Files\Rational\ClearCase\var\shipping\ms_ship\incoming\sync_boston_hub_07-
Dec-00.18.15.57_5978_1 to VOB \\ramohalli\vobs\dev.vbs
At the new master replica, verify that mastership has been received:
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 Chapter 9, Implementing Requests for Mastership.
To transfer mastership of a branch to another replica:
At the master replica, enter a chmaster command:
MINUTEMAN% multitool chmaster -c "bugfix at bangalore" bangalore Makefile@@/main
Changed mastership of branch "Makefile@@/main" to "bangalore"
At the old master replica, export an update packet to the new master replica's site:
MINUTEMAN% multitool syncreplica -export -fship bangalore@/vobs/dev
Generating synchronization packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_10-Dec-00.18.15.57_30
56_1
- shipping order file is
/usr/atria/shipping/ms_ship/outgoing/sh_o_sync_boston_hub_10-Dec-00.18.15.
57_3056_1
Attempting to forward/deliver generated packets...
-- Forwarded/delivered packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_10-Dec-00.18.15.57_30
56_1
At the new master replica, import the packet:
RAMOHALLI> multitool syncreplica -import -receive
Applied sync. packet C:\Program Files\Rational\ClearCase\var\shipping
\ms_ship\incoming\sync_boston_hub_10-Dec-00.18.15.57_3056_1 to VOB
\\ramohalli\vobs\dev.vbs
At the new master replica, verify that mastership has been received:
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:
At the replica that masters the branch, enter a chmaster -default command:
RAMOHALLI> multitool chmaster -default Makefile@@\main
Changed mastership of branch "Makefile@@\main" to "default"
Determine which replica masters the branch type:
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.
Export an update packet to the replica that masters the branch type:
RAMOHALLI> multitool syncreplica -export -fship boston_hub@\dev
Generating synchronization packet C:\Program
Files\Rational\ClearCase\var\shipping\ms_ship\outgoing\sync_bangalore_11-D
ec-00.18.15.57_9476_1
- shipping order file is
/usr/atria/shipping/ms_ship/outgoing/sh_o_sync_bangalore_11-Dec-00.18.15.5
7_9476_1
Attempting to forward/deliver generated packets...
-- Forwarded/delivered packet
/usr/atria/shipping/ms_ship/outgoing/sync_bangalore_11-Dec-00.18.15.57_947
6_1
At the replica that masters the branch type, import the packet:
MINUTEMAN% multitool syncreplica -import -receive
Applied sync. packet
/usr/atria/shipping/ms_ship/incoming/sync_bangalore_11-Dec-00.18.15.57_947
6_1 to VOB /net/minuteman/vobstg/dev.vbs
At the replica that masters the branch type, verify that the branch has default mastership:
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:
multitool chmaster -stream boston_hub@/vobs/dev stream:v2.1.bl5@/vobs/dev
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 detailed 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:
There are checkouts on the bangalore_main branch.
There is a lock on a label type.
Find the checkouts and either check in the files or cancel the checkouts:
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.
Unlock the type object.
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".
Reenter the chmaster command.
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.
If a mastership change is made in your replica by mistake, follow these steps to undo the change:
At your replica, complete the transfer by sending an update packet to the new master replica.
At the new master replica, complete these steps:
Import the packet.
Change mastership back to your replica.
Export an update packet to your replica.
At your replica, import the packet.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
