Planning the rules of the road

As part of our scenario, let's assume that the company uses subbranches for individual subprojects and then merges work between those subbranches and a common integration branch.

The details of the corporate development strategy are as follows:
  • Individual subprojects, and often individual developers, use separate subbranches. The auto-make-branch facility is used in all config specs, to place changes on the appropriate branches. For example:
    element * CHECKEDOUT
    element * .../sanfran_main/LATEST
    element * SANFRAN_BASE –mkbranch sanfran_main
    element * V1.0 –mkbranch sanfran_main
    element * /main/0 –mkbranch sanfran_main
    
  • The v2.0_integration branch type is reserved for integration of the work done at the various sites. To prepare for an internal baseline or an external release, the project manager merges selected development subbranches into the v2.0_integration branch.
  • When necessary, developers merge changes from the v2.0_integration branch to their subbranches, to bring themselves up to date with changes occurring on the integration branch.

With HCL VersionVault MultiSite , the organization can continue to use this strategy. The Boston replica masters the v2.0_integration branch type. The San Francisco replica masters a branch type named sanfran_main, and any additional branch types that may be needed to organize the work there. The project manager at the Boston site merges changes from the sanfran_main and boston_main branches into the v2.0_integration branch, so that the release engineers can build the product using the latest changes.

Relevant characteristics of the two replicas:

Boston replica
Host name minuteman (Linux® or the UNIX® system)
Replica name boston_hub
VOB storage directory /vobstg/dev.vbs
VOB tag /vobs/dev
Config spec for development element * CHECKEDOUT element * .../boston_main/LATEST element * BOSTON_BASE –mkbranch boston_main element * V1.0 –mkbranch boston_main element * /main/0 –mkbranch boston_main
Config spec for integration element * CHECKEDOUT element * .../v2.0_integration/LATEST element * BOSTON_BASE –mkbranch v2.0_integration element * V1.0 –mkbranch v2.0_integration element * /main/0 –mkbranch v2.0_integration
San Francisco replica
Host name goldengate (Linux or the UNIX system)
Replica name sanfran_hub
VOB storage directory /vobstg/dev.vbs
VOB tag /vobs/dev
Config spec for development element * CHECKEDOUT element * .../sanfran_main/LATEST element * SANFRAN_BASE –mkbranch sanfran_main element * V1.0 –mkbranch sanfran_main element * /main/0 –mkbranch sanfran_main

The company has not yet merged its user or group databases, so the two replicas cannot preserve identities. Because the administrators want to preserve changes to permissions, they decide to make the replicas permissions-preserving. There is IP connectivity between the two offices, so the Boston administrator can use the MultiSite store-and-forward facility to create the new replica.