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