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.
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.
Independent development: Mastership Modification management in multiple replicas: Mastership
Because changes are made independently at multiple replicas, these changes may conflict. In a MultiSite environment, tracking changes and preventing data corruption are accomplished with an exclusive-right-to-modify scheme called Mastership. Mastership determines when a user of a replica is allowed to modify data.

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.
    - Replicated VOB databases
      In HCL VersionVault MultiSite, developers at different geographic locations can use the same versioned object base (VOB), because each site has its own copy (replica) of the VOB.
    - HCL VersionVault MultiSite terminology
      HCL VersionVault MultiSite documentation uses the terms described in this section.
    - VOBs and VOB replicas
      In HCL VersionVault MultiSite, a VOB replica is a copy of a VOB, including both file system data (data containers) and metadata (VOB database). At each replica, developers can see all VOB elements and all versions of each element.
    - Replica synchronization in a family
      Because information in a replicated VOBHCL Compass database is modified concurrently at different replicas, the contents of each replica in a family tend to differ. The contents of a particular replica may never be identical to the contents of any other replica. To keep the replicas from differing too much, each replica sends updates to one or more other replicas. Updating a VOB replica changes both its database and its storage pools to reflect the development activity that has taken place in one or more other replicas.
    - Independent development: Mastership Modification management in multiple replicas: Mastership
      Because changes are made independently at multiple replicas, these changes may conflict. In a MultiSite environment, tracking changes and preventing data corruption are accomplished with an exclusive-right-to-modify scheme called Mastership. Mastership determines when a user of a replica is allowed to modify data.
    - Supporting serial development in VOB replicas
      The standard HCL VersionVault development model is to use branches to develop software in parallel, and the standard HCL VersionVault MultiSite model is to master different branch types at different replicas so that development can proceed concurrently at different replicas. These models require you to merge changes from branch to branch. However, sometimes sites must use serial development (for example, to make changes to elements whose versions cannot be merged).
  - 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 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.

Independent development: Mastership Modification management in multiple replicas: Mastership

Because changes are made independently at multiple replicas, these changes may conflict. In a MultiSite environment, tracking changes and preventing data corruption are accomplished with an exclusive-right-to-modify scheme called Mastership. Mastership determines when a user of a replica is allowed to modify data.

If the work done in different replicas were truly independent, the result would be chaos. Suppose version 17 of an element is created on the main branch in three replicas at the same time. Which is the real version 17, and what happens to the other versions? If a record SAMPL00001 is created in three replicas at the same time, it is impossible to determine which is the real record SAMPL00001 and what must happen to the other two records.

Certain objects are assigned a master replica (or master). The initial master of an object is the replica where the object is created, and mastership can be changed subsequently (see Managing mastership). In general, an object can be modified or deleted only at its master replica.

For example, each branch type has a master replica. By default, you can create or modify a branch only if your current replica masters the branch type. In this example, the command fails because the current replica does not master the main branch type:


cleartool checkout –c "add new feature" v3.0plan.doc 
cleartool: Error: Unable to perform operation "checkout" in replica 
"sanfran_hub" of VOB "/vobs/doc".
cleartool: Error: Master replica of branch "/main" is "boston_hub".
cleartool: Error: Unable to check out "v3.0plan.doc".

Replicas, VOBs, and most objects in a VOB have a master replica. For more information about how mastership prevents conflicting changes, see Mastership.

Most objects in a HCL Compass database have a master replica.

Some conflicts are unavoidable. For example, objects with the same name can be created at two or more VOB replicas during the same time period between synchronizationsa new user named jsmith can be created at two or more sites during the same time period between synchronizations. You can minimize such conflicts by establishing naming conventions for objects, but if a conflict does occur, it is handled during import of an update packet. For more information, see Conflict resolution.

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.