Home
Administering
Learn how to administer the product.
Administering HCL VersionVault MultiSite
Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
Administering replicas
Implementing requests for mastership
To support development of VOB elements that cannot be merged, you can give developers the ability to request mastership of branches and branch types.
Serial development scenario
This is an example of serial development using requests for mastership.
Requesting mastership
This scenario provides examples of how the writers use mastership requests to do their work.
Requesting mastership of a branch type
In this scenario, 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. To reduce the number of mastership requests for individual branches, the project leader requests mastership of the main branch type.

Administering
Learn how to administer the product.
- Administering HCL VersionVault
  Learn about performing administrative tasks for an HCL VersionVault community including managing software licenses, user and group accounts, VersionVault server and client hosts, shared data, and the network that connects them.
- Administering platforms for HCL VersionVault
  Learn how to perform HCL VersionVault administrative tasks on supported platforms.
- Administering HCL VersionVault MultiSite
  Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
  - Introduction
    HCL VersionVault MultiSite adds a powerful capability to HCL VersionVault. With MultiSite, developers at different locations can use the same HCL VersionVault versioned object base (VOB). For HCL VersionVault, each location (site) has its own copy (replica) of the VOB. At any time, changes made in one replica can be sent in update packets to other replicas. You can manage replicas by using the command-line tools.
  - MultiSite operation
  - Implementation planning
    Before you install and use HCL VersionVaultHCL Compass MultiSite, you need to plan your implementation.
  - MultiSite command set
    This section summarizes the commands for HCL VersionVault MultiSite and HCL VersionVault that display HCL VersionVault MultiSite information. There are a series of MultiSite commands and API functions that display or modify MultiSite information.
  - Packet transportation methods and configuration
    The method you choose for transporting packets between replicas depends on connectivity. If your replicas do not have IP connectivity, you must use a file-based transport method. If your replicas have connectivity, you can use the store-and-forward facility.
  - Feature levels
    Feature levels allow different replica hosts in a VOB family to run different versions of HCL VersionVault. You can raise the feature level of either a single replica host or an entire VOB family.
  - Creating VOB replicas
    Before creating a replica, you must make decisions about branching, mastership, identities and permissions preservation, and method of packet delivery.
  - Replica synchronization
    Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
  - Administering replicas
    - Using the CLI and native GUIs
    - Managing mastership
    - Implementing requests for mastership
      To support development of VOB elements that cannot be merged, you can give developers the ability to request mastership of branches and branch types.
      - Overview of a request for mastership
        When a developer requests mastership of a branch, the branch's mastership is transferred to the developer's current replica. When a developer requests mastership of a branch type, mastership of the branch type, along with mastership of all the instances of the branch type that have default mastership, is transferred to the developer's current replica.
      - Requirements and recommendations
        In order to enable requests for mastership in one or more replicas and for those requests to be handled efficiently, specific conditions must be met.
      - Planning your implementation
        Before enabling requests for mastership, the project managers and administrators at the different sites must make specific planning decisions about whether requests for mastership are allowed for specific replicas, branches, and branch types, and which developers are authorized to make requests for mastership.
      - 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.
      - Enabling synchronous requests for mastership (SRFM)
        Synchronous request for mastership (SRFM) means that a request for mastership of a branch is issued synchronously with a checkout of that remotely mastered branch, providing a writable branch before branch mastership is acquired.
      - Customizing synchronization updates for mastership requests
        After a mastership request is processed at the master replica, sync_export_list is invoked to export an update packet to the replica at the requester's site. You can customize the export by specifying one or more of the options and arguments that are valid for sync_export_list, except for –replicas, which is always the replica at the requester's site.
      - Displaying mastership request settings
        To display the mastership request setting for a replica, branch type, or branch, use the describe command or the Mastership page in the Properties Browser (Windows®). These settings are also displayed in the Request Mastership Window on Windows.
      - Troubleshooting mastership requests
        MultiSite provides commands you can use to troubleshoot failed mastership requests. When a request fails, the error messages provide an indication of what happened and what can be done to fix the problem.
      - Serial development scenario
        This is an example of serial development using requests for mastership.
        Planning the implementation
        In the serial development example, the company PurpleDoc develops documentation at three sites, using two VOB families.
        Setting up access controls
        Based on decisions made by administrators and project managers, the MultiSite administrators at each site configure access control for their site.
        Writing config specs
        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.
        Requesting mastership
        This scenario provides examples of how the writers use mastership requests to do their work.
        Serial development of a file that cannot be merged
        In this scenario, a writer cannot currently check out the file using a reserved checkout because the branch is mastered by a different replica. She waits until she receives mastership before proceeding with her checkout.
        Serial development of a file that can be merged
        In this scenario, a writer cannot currently check out the file using a reserved checkout because the branch is mastered by a different replica. He checks out the file using the –unreserved and –nmaster options. After he receives mastership, he finds that he must merge the changes before he can complete his checkin operation.
        Requesting mastership of a branch type
        In this scenario, 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. To reduce the number of mastership requests for individual branches, the project leader requests mastership of the main branch type.
  - Using MultiSite for VOB backup and interoperability
    You can use HCL VersionVault MultiSite to back up a VOB and to provide access to VOBs in a heterogeneous network.
  - Troubleshooting MultiSite operations
    When you encounter a situation where running an HCL VersionVault MultiSite command produces an unexpected result, or produces a warning or error message, the information in this section can assist you in troubleshooting the problem.

Requesting mastership of a branch type

In this scenario, 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. To reduce the number of mastership requests for individual branches, the project leader requests mastership of the main branch type.

She requests mastership of the 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.

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