16.9 Creating Baseline 2

The MIN team is ready to freeze for Baseline 2, and the MAJ team will be soon (Figure 55). Baseline 2 will integrate all three development efforts, thus requiring two sets of merges:

• Bug fix changes from the most recent patch release (versions labeled R1.0.2) must be merged to the main branch.

• New features must be merged from the major branch to the main branch. (This is the opposite direction from the merges described in Merging Ongoing Development Work.)

Figure 55 Baseline 2

ClearCase supports merges from more than two directions, so both the bug fixes and the new features can be merged to the main branch at the same time. In general, though, it is easier to verify the results of two-way merges.

Merging from the r1_fix Branch

The first set of merges is almost identical to those described in Merging Two Branches.

Preparing to Merge from the major Branch

After the integration of the r1_fix branch is completed, the project manager prepares to manage the merges from the major branch. These merges are performed in a tightly controlled environment, because the Baseline 2 milestone is approaching and the major branch is to be abandoned.

NOTE: It is probably more realistic to build and verify the application, and then apply version labels before proceeding to the next merge.

The project manager verifies that everything is checked in on both the main branch and major branches:

Y:\> cleartool lscheckout -brtype main -recurse \monet \libpub
Y:\> cleartool lscheckout -brtype major -recurse \monet \libpub
Y:\>

No output from these commands indicates that no element is checked out on either its main branch or its major branch.

Next, the project manager determines which elements require merges:

Y:\> net use x: \\view\minor_vu (use any MIN team view)
Y:\> x:
X:\> cleartool findmerge \monet \libpub -fversion ...\major\LATEST -print
.
. <lots of output>
.
A 'findmerge' log has been written to
"findmerge.log.26-Feb-99.19.18.14"

All development on the major branch will stop after this baseline. Thus, the project manager locks the major branch to all users, except those who are performing the merges. Locking allows ClearCase to record the merges with a hyperlink of type Merge:

X:\> cleartool lock -nusers arb,david brtype:major@\monet brtype:major@\libpub
Locked branch type "major".
Locked branch type "major".

Because the main branch will be used for Baseline 2 integration by a small group of developers, the project manager asked vobadm to lock the main branch to everyone else:

X:\> cleartool lock -nusers meister,arb,david,sakai ^
brtype:main@\monet brtype:main@\libpub
Locked branch type "main".
Locked branch type "main".

(To lock the branch, you must be the branch creator, element owner, VOB owner, or a member of the ClearCase administrators group. See the lock reference page.)

Merging from the major Branch

Because the main branch is the destination of the merges, developers work in a view with the default config spec. The situation is similar to the one described in Preparing to Merge. This time, the merges take place in the opposite direction, from the major branch to the main branch. Accordingly, the findmerge command is very similar:

X:\> cleartool findmerge \monet \libpub -fversion \main\major\LATEST ^
-merge -graphical
.
. <lots of output>
.
A 'findmerge' log has been written to
"findmerge.log.23-Mar-99.14.11.53"

After checkin, the version tree of a typical merged element appears as in Figure 56.

Figure 56 Element Structure After the Pre-Baseline-2 Merge

Decommissioning the major Branch

After all data has been merged to the main branch, development on the major branch will stop. The project manager enforces this policy by making the major branch obsolete:

X:\> cleartool lock -replace -obsolete brtype:major@\monet brtype:major@\libpub
Locked branch type "major".
Locked branch type "major".

Integration and Test

Structurally, the Baseline 2 integration-and-test phase is identical to the one for Baseline 1 (see Integration and Test). At the end of the integration period, the project manager attaches version label R2_BL2 to the \main\LATEST version of each element in the monet and libpub VOBs. (The Baseline 1 version label was R2_BL1.)