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.

Tip: 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:

% cleartool lscheckout -brtype main –recurse /vobs/monet /vobs/libpub
% cleartool lscheckout -brtype major –recurse /vobs/monet /vobs/libpub


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:

%cleartool setview minor_vu

Any MIN team view can be used.

%cleartool findmerge /vobs/monet /vobs/libpub -fversion .../major/LATEST –print

A 'findmerge' log has been written to

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 the merges to be recorded with a hyperlink of type Merge:

%cleartool lock -nusers arb,david brtype:major@/vobs/monet 
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:

%cleartool lock -nusers meister,arb,david,sakai \
brtype:main@/vobs/monet brtype:main@/vobs/libpub
Locked branch type "main".
Locked branch type "main".

To lock the branch, you must be the branch creator, element owner, VOB owner, or root user (on Linux or the UNIX system) or a member of the VersionVault administrators group (on the Windows® system). See the lock reference page.