Transfers mastership of VOB-database object
Product | Command type |
---|---|
ClearCase | cleartool subcommand |
MultiSite | multitool subcommand |
Platform |
---|
UNIX |
Windows |
This command transfers the mastership of one or more objects from one VOB replica to another. Only the current replica is affected immediately; other replicas are notified of the mastership transfers through the normal exchange of update packets.
To limit use of this command to a certain set of users, you can create triggers. For more information, see Managing Software Projects.
The chmaster command requires a view context. If you are not in a set view or working directory view on UNIX or a view drive on Windows, you can specify a view on the command line, as shown in the following table. If you specify a dynamic view, it must be active on your host.
NOTE: A view you specify in the chmaster command takes precedence over your current set view, working directory view, or view drive.
Argument | How to specify a view |
---|---|
object-selector | Use a view-extended pathname as the vob-selector portion of the argument. For example: lbtype:LABEL1@/view/jtg/vobs/dev |
branch-pname | Specify branch-pname or element-pname as a view-extended pathname. For example: /view/jtg/vobs/dev/cmd.c@@ |
master-replica-selector (for the chmaster -all variant) | Use the -view option or use a view-extended pathname as the vob-selector portion of the argument. For example: -view jtg replica:boston_hub@\dev |
Identities: For all UCM objects except baselines, no special identity is required. For baselines and all other non-UCM objects, you must have one of the following identities:
Object creator (except for replicas)
Object owner (except for replicas)
VOB owner
root (UNIX)
Member of the ClearCase administrators group (Windows)
Object whose mastership is changing | Locks on these objects cause the chmaster command to fail |
---|---|
Element | Element, element type, VOB |
Branch | Branch, branch type, VOB |
Type object | Type object, VOB |
Hyperlink | Hyperlink type, VOB |
Baseline | Baseline, VOB, replica, components associated with the baseline |
Stream | Stream, activity |
Component | Component, VOB, replica |
Mastership: Your current replica must master the object. Using both -all and -obsolete_replica overrides this restriction, but you must not use the -obsolete_replica option except in special circumstances. (See the description of the -all option.)
Other: You cannot transfer mastership of a branch if the branch is checked out reserved or if it is checked out unreserved without the -nmaster option.
EVENT RECORDS AND COMMENTS. Default: Creates one or more event records, with commenting controlled by the standard ClearCase user profile (default: -nc). See EVENT RECORDS AND COMMENTS in the multitool reference page. To edit a comment, use cleartool chevent.
SPECIFYING THE OBJECTS. Default: None.
replica-name | Name of the replica (displayed with lsreplica) | |
vob-selector | VOB family of the replica; can be omitted if the current working directory is within the VOB. Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
vob-selector | vob:pname-in-vob where pname-in-vob |
Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
attribute-type-selector | [attype:]type-name[@vob-selector] | |
branch-type-selector | [brtype:]type-name[@vob-selector] | |
element-type-selector | [eltype:]type-name[@vob-selector] | |
hyperlink-type-selector | [hltype:]type-name[@vob-selector] | |
label-type-selector | [lbtype:]type-name[@vob-selector] | |
hlink-selector | [hlink:]hlink-id[@vob-selector] | |
oid-obj-selector | oid:object-oid[@vob-selector] | |
replica-selector | [replica:]replica-name[@vob-selector] | |
baseline-selector | [baseline:]baseline-name[@vob-selector] | |
component-selector | [component:]component-name[@vob-selector] |
stream-selector | [stream:]stream-name[@vob-selector] |
With -obsolete_replica, chmaster transfers mastership of all objects in the replica specified with old-replica-selector. Also, chmaster associates nonmastered checkouts with the new replica. Use this form of chmaster only when replica old-replica-selector is no longer available (for example, was deleted accidentally). Before entering this command, you must make sure that old-replica-selector masters itself or is mastered by the replica that it last updated. Then, enter the chmaster command at the last-updated replica. You must also send update packets from the last-updated replica to all other remaining replicas in the VOB family. For more information, see the rmreplica reference page.
RETURNING MASTERSHIP OF BRANCHES TO DEFAULT STATE. Default: None.
At replica boston_hub, transfer mastership of label type V1.0_BUGFIX to the sanfran_hub replica.
multitool chmaster sanfran_hub lbtype:V1.0_BUGFIX
Changed mastership of "V1.0_BUGFIX" to "sanfran_hub"
At replica sanfran_hub, transfer mastership of element list.c to the sydney replica.
multitool chmaster sydney list.c@@
Changed mastership of "list.c" to "sydney"
At replica sanfran_hub, 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
At the replica that is the master of replica sanfran_hub, make sanfran_hub self-mastering.
multitool chmaster sanfran_hub replica:sanfran_hub
Changed mastership of "sanfran_hub" to "sanfran_hub"
At replica buenosaires, transfer mastership of branch cache.c@@/main/v3_dev to boston_hub.
multitool chmaster boston_hub cache.c@@/main/v3_dev
Changed mastership of branch "/vobs/dev/cache.c@@/main/v3_dev" to
"boston_hub"
For all objects mastered by the current replica, transfer mastership to sanfran_hub.
multitool chmaster -all sanfran_hub
Changed mastership of all objects
Same as the preceding example, but have chmaster list each object whose mastership is changing, and specify a view context.
multitool chmaster -all -long sanfran_hub@/view/jtg/vobs/dev
Changed mastership of branch type sydney_main
Changed mastership of label type SYDNEY_V2.0
Changed mastership of replica sydney
Changed mastership of all objects
Return mastership of a branch to the replica that masters the branch type, and then remove its explicit mastership.
At the replica that masters the branch:
multitool describe -fmt "%[master]p\n" brtype:v3_bugfix
boston_hub@\dev
multitool chmaster boston_hub@\dev \dev\acc.c@@\main\v3_bugfix
Changed mastership of branch "\dev\acc.c@@\main\v3_bugfix" to
"boston_hub@\dev"
multitool syncreplica -export -fship boston_hub@\dev
Generating synchronization packet c:\Program Files\Rational\ClearCase\var
\shipping\ms_ship\outgoing\sync_bangalore_19-Aug-00.09.33.02_3447_1
...
At the replica that masters the branch type:
multitool syncreplica -import -receive
Applied sync. packet
/var/adm/atria/shipping/ms_ship/incoming/sync_bangalore_19-Aug-00.09.33.02
_3447_1
to VOB /net/minuteman/vobstg/dev.vbs
multitool chmaster -default brtype:v3_bugfix
Changed mastership of branch type "v3_bugfix" to "default"
reqmaster, syncreplica
Chapter 8, Managing Mastership in the Administrator's Guide for Rational ClearCase MultiSite.
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |