This section describes an example of serial development using requests for mastership.
The company PurpleDoc develops documentation at three sites. There are two VOB families:
The writers working in /vobs/doc use serial development because the files are in binary format. However, a team of writers in Boston needs control of a certain set of files at all times.
The writers working on HTML files in /vobs/html use site-specific branch types: boston_main, tokyo_main, and sanfran_main. Writers at a particular site cannot use branch types mastered by replicas at other sites.
The tool developers working on scripts use the main branch. Because the scripts can be merged, the developers can use nonmastered checkouts to do their work.
The administrators and project managers at the Boston, San Francisco, and Tokyo sites make the following decisions:
Each administrator completes the following steps on the replica’s VOB server host. (This example takes place at the Boston site.)
multitool reqmaster –deny /vobs/doc/plans/v3.0.doc@@/main /vobs/doc/plans/schedule.doc@@/main /vobs/doc/plans/roadmap.doc@@/main
multitool reqmaster –deny –instances brtype:boston_main@/vobs/html
multitool reqmaster –deny brtype:boston_main@/vobs/html
multitool reqmaster –enable vob:/vobs/doc vob:/vobs/html
In this scenario, the writers use the config specs listed below. 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.
# Boston config spec element * CHECKEDOUT element /vobs/html/scripts/... /main/LATEST element /vobs/html/files/... /main/boston_main/LATEST element /vobs/html/files/... /main/LATEST -mkbranch boston_main element * /main/LATEST# San Francisco config spec element * CHECKEDOUT element /vobs/html/scripts/... /main/LATEST element /vobs/html/files/... /main/sanfran_main/LATEST element /vobs/html/files/... /main/LATEST -mkbranch sanfran_main element * /main/LATEST# Tokyo config spec element * CHECKEDOUT element /vobs/html/scripts/... /main/LATEST element /vobs/html/files/... /main/tokyo_main/LATEST element /vobs/html/files/... /main/LATEST -mkbranch tokyo_main element * /main/LATEST
The following sections describe how the writers use mastership requests to do their work.
cleartool checkout –c "new command options" update.fm cleartool: Error: Unable to perform operation "checkout" in replica "tokyo" of VOB "\doc". cleartool: Error: Master replica of branch "\main" is "boston_hub". cleartool: Error: Unable to check out "update.fm".
cleartool reqmaster –c "Tokyo needs mastership" update.fm@@\main update.fm@@\main: Change of mastership at sibling replica "boston_hub" was successful. Mastership is in transit to the new master replica.
cleartool describe –fmt "%[master]p\n" update.fm@@\main tokyo@\doc
cleartool checkout –c "new command options" update.fm Checked out "update.fm" from version "\main\30".
cleartool checkout –c "option to suppress status msgs" /vobs/html/scripts/conv_fm.pl cleartool: Error: Unable to perform operation "checkout" in replica "sanfran_hub" of VOB "/vobs/html". cleartool: Error: Master replica of branch "/main" is "boston_hub". cleartool: Error: Unable to check out "/vobs/html/scripts/conv_fm.pl".
cleartool reqmaster –c "SF: add new option" /vobs/html/scripts/conv_fm.pl@@/main /vobs/html/scripts/conv_fm.pl@@/main: Change of mastership at sibling replica "boston_hub" was successful. Mastership is in transit to the new master replica.
cleartool checkout –c "option to suppress status msgs" –unreserved –nmaster /vobs/html/scripts/conv_fm.pl Checked out "/vobs/html/scripts/conf_fm.pl" from version "/main/15".
cleartool checkin –nc conv_fm.pl cleartool: Error: Unable to perform operation "checkin" in replica "sanfran_hub" of VOB "/vobs/html". cleartool: Error: Master replica of branch "/main" is "boston_hub". cleartool: Error: Unable to check in "conv_fm.pl".
cleartool checkin –nc conv_fm.pl cleartool: Error: The most recent version on branch "/main" is not the predecessor of this version. cleartool: Error: Unable to check in "conv_fm.pl".
cleartool merge –to conv_fm.pl –c "merging from LATEST" –version /main/LATEST ******************************** <<< file 1: /vobs/html/conv_fm.pl@@/main/15 >>> file 2: /vobs/html/conv_fm.pl@@/main/16 >>> file 3: conv_fm.pl ******************************** . . . Moved contributor "conv_fm.pl" to "conv_fm.pl.contrib". Output of merge is in "conv_fm.pl". Recorded merge of "conv_fm.pl".
cleartool checkin –nc conv_fm.pl Checked in "conv_fm.pl" version "/main/17".
The Boston developers have been using nonmastered checkouts to work on scripts, and their project leader decides that all the changes need to be checked in. In order to reduce the number of mastership requests for individual branches, the project leader requests mastership of the main branch type.
cleartool reqmaster –c "merging party in Boston" brtype:main@/vobs/html brtype:main@/vobs/html: Change of mastership at sibling replica "sanfran_hub" was successful. Mastership is in transit to the new master replica.
cleartool describe –fmt "%[master]p\n" brtype:main@/vobs/html boston_hub@/vobs/html
All of the branches that had default mastership are now mastered by the Boston replica. If any of the branches were explicitly mastered by the San Francisco or Tokyo replicas, their mastership was not changed. Developers must request mastership for those specific branches.
The developers in Boston can perform necessary merges and check in their changes.