Enabling requests for mastership

To enable requests for mastership for the replicas in a VOB family, you must verify the feature level, add developers to the access control list, specify any objects for which you want to deny requests, and then enable requests at the replica level for each replica in the VOB family.

About this task

These procedures use the command line. On Windows®, you can also use the ACL editor and the Properties Browser.

Procedure

  1. Verify that the feature level of each replica in the VOB family is the correct value, and that the VOB family’s feature level is the correct value. For instructions, see Feature levels.
  2. At each replica, add the appropriate people to the replica’s access control list.
    multitool reqmaster –acl –edit vob-selector
    

    A replica’s access control list (ACL) contains a list of users at other sites who are allowed to request mastership of branches and branch types mastered by that replica. To modify this file, you must be VOB owner, root (on Linux® and the UNIX® system), a member of the DevOps Code ClearCase administrators group (on Windows), or have write permissions on the ACL.

    The vob-selector specifies a VOB family, and the ACL for your current replica is changed.

    An access control list contains lines of the following form:

    identity-specification access-level,...
    

    identity-specification is one of the following:

    Everyone
    Everyone in all domains.
    Domain:domain
    Everyone in the specified domain.
    Group:domain /group
    Everyone in the specified group in domain. You can use a slash ( / ) or backslash ( \ ) between domain and group.
    User:domain /username
    A specific user in a particular domain. You can use a slash ( / ) or backslash ( \ ) between domain and username.

    On Windows, domain is the name of a Windows domain (for example, purpledoc). On Linux and the UNIX system, domain is an NIS domain name (for example, purpledoc.com). If someone who can request mastership has user names in multiple domains, you must specify all the identities in the ACL.

    access-level is one or more of the following:

    Read
    Allow read access on ACL
    Write
    Allow write access on ACL
    Change
    Allow requests for mastership
    Full
    Allow requests for mastership and read/write access on ACL

    Separate multiple access levels with a comma and no white space. The identity specification and associated access levels must appear on the same line.

    For example, the following ACL specifies that susan can modify the ACL, and jcole and kumar can request mastership:

    User:purpledoc.com/susan Read,Write
    User:purpledoc/susan Read,Write
    User:purpledoc.com/jcole Change
    User:purpledoc/jcole Change
    User:purpledoc.com/kumar Change
    User:purpledoc/kumar Change
    

    The following ACL gives msadm full permissions and allows everyone to request mastership:

    User:purpledoc.com/msadm Full
    User:purpledoc/msadm Full
    Everyone Change
    
  3. At each replica, deny requests for mastership of specific objects. By default, requests are allowed for all branches and branch types.

    For example:

    multitool reqmaster –deny branch-pname
    Denies requests for mastership of the specified branch.
    multitool reqmaster –deny branch-type-selector
    Denies requests for mastership of the specified branch type.
    multitool reqmaster –deny –instances branch-type-selector
    Denies requests for mastership of all instances of the specified branch type.

    For you to allow or deny mastership requests for a branch or branch type, your current replica must master it. You can allow or deny mastership requests for all instances of a branch type even if your current replica does not master the type.

    If the branch type is a global type, its mastership request setting is stored in the administrative VOB and applies to all local copies of the branch type.

  4. At each replica, enable requests for mastership at the replica level.
    multitool reqmaster –enable vob-selector
    

    The vob-selector specifies a VOB family, and your current replica is enabled for mastership requests. You must enter this command on the VOB server host.

    To enable or disable permission at the replica level, you must be the VOB owner, root (Linux and the UNIX system), or a member of the DevOps Code ClearCase administrators group (Windows). Also, the replica must master its own replica object.

    In an administrative VOB hierarchy, you enable requests for mastership in the VOB replicas linked to the administrative VOB. You do not have to enable requests in the administrative VOB replica unless it contains elements that are developed serially.

Results

After you enable requests for mastership, inform the appropriate developers about mastership requests and how and when to use them. For details about working on a development team, see Developing Software, which describes the procedures developers must use to request mastership.

Note: The reqmaster command is a cleartool subcommand as well as a multitool subcommand. Developers who will request mastership do not have to install MultiSite software on their client hosts. On Windows, developers can request mastership from the Find Checkouts window, the Merge Manager, and the Version Tree Browser.