Serial Development Scenario


This section describes an example of serial development using requests for mastership.

Planning the Implementation

The company PurpleDoc develops documentation at three sites. There are two VOB families:

Setting Up Access Controls

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.)

  1. Add writers at other sites to the ACL for /vobs/doc.
    1. Place the following lines in the file /tmp/doc_acl:
    2. # Replica boston_hub@/vobs/doc
      # Request for Mastership ACL:
      User:boston.purpledoc.com/msadm Full
      User:tokyo.purpledoc.com/masako Change
      User:tokyo.purpledoc.com/sato Change
      User:tokyo.purpledoc.com/ito Change
      User:sf.purpledoc/jcole Change
      User:sf.purpledoc/marni Change
      User:sf.purpledoc/david Change

    3. Use the file to set the replica’s ACL:
    4. multitool reqmaster –acl –set /tmp/doc_acl vob:/vobs/doc 

  2. Add tool developers at other sites to the ACL for /vobs/html.
    1. Place the following lines in the file /tmp/html_acl:
    2. # Replica boston_hub@/vobs/html
      # Request for Mastership ACL:
      User:boston.purpledoc.com/ccadmin Full
      User:tokyo.purpledoc.com/masako Change
      User:sf.purpledoc/david Change

    3. Use the file to set the replica’s ACL:
    4. multitool reqmaster –acl –set /tmp/html_acl vob:/vobs/html 

      Note: After you set the ACL, you can delete the temporary ACL files you created.

  3. Deny mastership requests for specific branches and branch types:
  4. 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 
  5. Enable requests for mastership at the replica level.
  6. multitool reqmaster –enable vob:/vobs/doc vob:/vobs/html 

Writing Config Specs

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

Requesting Mastership

The following sections describe how the writers use mastership requests to do their work.

Serial Development of a File That Cannot Be Merged

  1. Masako, in Tokyo, tries to check out the file \doc\ref\update.fm, but the checkout fails because the Tokyo replica doesn’t master the main branch:
  2. 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".
  3. She requests mastership of branch update.fm@@\main:
  4. 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.
  5. Periodically, she retries the checkout or displays properties of the branch to determine whether mastership has been received. After mastership is received at her replica, the describe command shows that her replica masters the branch and her checkout succeeds:
  6. 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".

Serial Development of a File That Can Be Merged

  1. John, in San Francisco, needs to change a script. He can’t check out the file using a reserved checkout because the branch is mastered by the Boston replica:
  2. 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".
  3. He requests mastership of the branch:
  4. 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.
  5. He checks out the file with the –unreserved and –nmaster options and proceeds to edit the file:
  6. 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".
  7. Until mastership is received at the San Francisco replica, he cannot check in his changes:
  8. 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".
  9. When mastership is received at the San Francisco replica, he attempts to check in the file, but finds that he must perform a merge:
  10. 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".
  11. He performs the merge, and checks in the file:
  12. 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".

Requesting Mastership of a Branch Type

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.

  1. She requests mastership of the branch type:
  2. 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.
  3. Periodically, she displays properties of the branch type to determine whether mastership has been received. After mastership is received at her replica, the describe command shows that her replica masters the branch type.
  4. 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.