16.7 Creating Baseline 1

The MIN team has implemented and tested the first group of minor enhancements, and the FIX team has produced a patch release, whose versions are labeled R1.0.1. It is time to combine these efforts, to produce Baseline 1 of Release 2.0 (Figure 52).

Figure 52 Creating Baseline 1

Merging Two Branches

The project manager asks the MIN developers to merge the R1.0.1 changes from the r1_fix branch to their own branch (main). All the changes can be merged by using the findmerge command once. For example:

cleartool> findmerge \libpub \monet\src ^
-fversion ...\r1_fix\LATEST -merge -graphical
.
. <lots of output>
.

Integration and Test

After the merges are complete, the \main\LATEST versions of certain elements represent the efforts of the MIN and FIX teams. Members of the MIN team now compile and test the monet application to find and fix incompatibilities in the work of both teams.

The developers on the MIN team integrate their changes in a single, shared view. The project manager creates the view storage area in a shared directory that is accessible from all developer hosts:

C:\> mkdir c:\vw_store
C:\> net share c c:\
C:\> cleartool mkview -tag base1_vu \\nt_svr\c\vw_store\base1_vu.vws
Created view.
Host-local path: nt_svr:C:\vw_store\base1_vu.vws
Global path: \\nt_svr\c\vw_store\base1_vu.vws

Because all integration work takes place on the main branch, there is no need to change the configuration of the new view from the ClearCase default. MIN developers use this view (net use drive: \\view\base1_vu) and coordinate builds and tests of the monet application. Because they are sharing a single view, the developers are careful not to overwrite each other's view-private files. Any new versions created to fix inconsistencies (and other bugs) go onto the main branch.

Labeling Sources

The monet application's minor enhancements and bug fixes are now integrated, and a clean build has been performed in view base1_vu. To create the baseline, the project manager assigns the same version label, R2_BL1, to the \main\LATEST versions of all source elements. He begins by creating an appropriate label type:

Z:\> cleartool mklbtype -c "Release 2, Baseline 1" R2_BL1@\monet R2_BL1@\libpub
Created label type "R2_BL1".
Created label type "R2_BL1".

He then locks the label type, preventing all developers (except himself) from using it:

Z:\> cleartool lock -nusers meister lbtype:R2_BL1@vob:\monet lbtype:R2_BL1@\libpub
Locked label type "R2_BL1".
Locked label type "R2_BL1".

Before applying labels, he verifies that all elements are checked in on the main branch (checkouts on other branches are still permitted):

Z:\> cleartool lscheckout -all \monet

Z:\> cleartool lscheckout -all \libpub

No output from this command indicates that all elements for the monet project are checked in. Now, the project manager attaches the R2_BL1 label to the currently selected version (\main\LATEST) of every element in the two VOBs:

Z:\> cleartool mklabel -recurse R2_BL1 \monet \libpub
Created label "R2_BL1" on "\monet" version "\main\1".
Created label "R2_BL1" on "\monet\src" version "\main\3".
<many more label messages>

Removing the Integration View

The view registered as base1_vu is no longer needed, so the project manager removes it:

C:\> cleartool rmview -force -tag base1_vu