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.
MultiSite operation
Mastership
Branch mastership
Branch mastership is the scheme that supports independent development work at different VOB replicas. Every branch type defined in a VOB (including the main branch type) has a master replica.
Synchronizing development on different branches
Development of an element with multiple branches can take place in different replicas concurrently, with occasional synchronizations. The more frequently you update, the easier it is to track and reconcile the changes on different branches of elements.

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
    - Information propagated among VOB replicas
      Not all information is replicated across replicas. (For example, in general, site-specific information is not replicated.) This section shows what information is and is not propagated among replicas.
    - VOB objects and VOB replica objects
      Each replica is a VOB, but the VOB object and VOB-replica object are different objects in the VOB database.
    - Mastership
      - Replica mastership
        When you create a new replica, its replica object (the database object that records the replica’s existence) is mastered by the creating replica. Therefore, you can modify or delete the replica object only at the creating replica, unless you transfer mastership to another replica.
      - Branch mastership
        Branch mastership is the scheme that supports independent development work at different VOB replicas. Every branch type defined in a VOB (including the main branch type) has a master replica.
        Creation of the main branch of an element
        There is an exception to the rule that a branch can be created only at the master replica of the branch type. When you add a file to source control or create a new directory element, the main branch is created even if your current replica does not master the main branch type.
        Synchronizing development on different branches
        Development of an element with multiple branches can take place in different replicas concurrently, with occasional synchronizations. The more frequently you update, the easier it is to track and reconcile the changes on different branches of elements.
        Default and explicit branch mastership
        Branches can have default mastership or explicit mastership. When a branch is created, it is mastered by the replica that masters the branch type (default mastership). When you transfer mastership of a branch to another replica, that replica masters the branch explicitly.
      - Type object mastership
        There are mastership issues to consider when creating attribute, hyperlink, and label type objects, particularly when creating instances of those type objects across replicas is required.
      - Mastership restrictions for VOB objects
        Many MultiSite operations on VOB objects are subject to mastership restrictions.
    - Conflict resolution
    - The operation log
  - 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.

Synchronizing development on different branches

Development of an element with multiple branches can take place in different replicas concurrently, with occasional synchronizations. The more frequently you update, the easier it is to track and reconcile the changes on different branches of elements.

To reconcile changes, you use the HCL VersionVault version-comparison and merge facilities.)

For example, before the Boston site starts using MultiSite, the element cmdsyn.c has two branches, cmdsyn.c@@/main and cmdsyn.c@@/main/v1.0_integration:

When the Boston site starts using MultiSite, the administrator creates a new replica for the San Francisco site. Because integration for Version 1.0 will be done at the San Francisco site, the sanfran_hub replica must master the v1.0_integration branch type. The administrator transfers mastership of the v1.0_integration branch type to the sanfran_hub replica.

Developers in San Francisco can now create versions on existing branches of type v1.0_integration and can create new instances of that branch type. Work continues on the main branch in Boston:

The administrators at the Boston and San Francisco sites decide to merge some of the work on the v1.0_integration branch with the work done on the main branch. The San Francisco administrator sends an update packet to the boston_hub replica, and the Boston administrator imports it:

The Boston administrator then merges from the v1.0_integration branch to the main branch by checking out the latest version on the main branch, merging from the latest version on the v1.0_integration branch, and checking in the result of the merge:

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.