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
Using the CLI and native GUIs
Listing the synchronization history of a VOB replica
The lshistory command and the History Browser (lshistory –graphical) list the synchronization history of a replica.

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
      - Displaying properties of a VOB replica
        You can display properties of a VOB replica using the describe command or the VersionVault Properties Browser.
      - Listing the synchronization history of a VOB replica
        The lshistory command and the History Browser (lshistory –graphical) list the synchronization history of a replica.
      - Changing preservation mode for a VOB family
        You can change the preservation mode of a replica using the chreplica command.
      - Changing the host name for a VOB replica
        You can use the chreplica command (or the Property Browser on Windows) to change the host name for a VOB replica.
      - Setting the connectivity property for a VOB replica
        To indicate whether a sibling replica has IP connectivity to your current replica, use the chreplica command with the –isconnected or –nconnected option.
      - Renaming a VOB replica
        You can change the name of a VOB replica using either the cleartool rename command or the HCL VersionVault Properties Browser.
      - Moving a VOB replica
        Moving a VOB replica is similar to moving an unreplicated VOB. However, there are special considerations when you move a replicated VOB.
      - Changing mastership of a VOB replica
        You can use the chmaster command to change the mastership of a VOB replica.
      - Deleting a replica
        This topic describes how to remove a replica. You must complete all steps; if you do not, synchronization and mastership problems can occur in other replicas in the family. When you remove a replica, the replicas in its family stop tracking epoch numbers for that replica. Removing a replica does not delete the VOB database it replicates. Removing a replica requires two synchronization cycles: one to transfer mastership of all of the replica's objects to another replica, and one to inform all other replicas that the removed replica is no longer participating in the update process. Because this information can be communicated only through the synchronization process, you cannot remove a replica at its own site, because doing so prevents the replica from creating update packets. After a replica is removed from a family, it no longer participates in synchronization activities. The replica no longer updates its oplog, and you cannot transfer mastership of any object in that replica.
    - 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.
  - 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.

Listing the synchronization history of a VOB replica

The lshistory command and the History Browser (lshistory –graphical) list the synchronization history of a replica.

The output differs for your current replica and its sibling replicas:

When you list the history of your current replica, the output includes import events.
When you list the history of a sibling replica, the output includes export events from your current replica to the sibling replica.

For example, if you invoke lshistory on your current replica (and specify your current replica (boston_hub ) as the argument to the command), all imports to your current replica are listed:

cleartool lshistory replica:boston_hub@/vobs/dev

 17-Aug.11:05   susan     import sync from replica "sanfran_hub"
 to replica "boston_hub"
  "Imported synchronization information from replica "sanfran_hub".
  Row at import was: boston_hub=34 sanfran_hub=0"
...

If you invoke lshistory on your current replica and specify another replica ( sanfran_hub) as the argument, all exports to that replica are listed:

cleartool lshistory replica:sanfran_hub@/vobs/dev
17-Aug.11:11   susan     export sync from replica "boston_hub" to 
replica "sanfran_hub"
  "Exported synchronization information for replica "sanfran_hub".
  Row at export was: boston_hub=34 sanfran_hub=10"
17-Aug.10:54   susan     export sync from replica "boston_hub" to 
replica "sanfran_hub"
  "Exported synchronization information for replica "sanfran_hub".
  Row at export was: boston_hub=0 sanfran_hub=0"
16-Aug.09:49   susan     create replica "sanfran_hub"

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.