Merging work

Because the MAJ team is not contributing to a baseline soon, it is not necessary to merge work (and test the results) in a shared view. MAJ developers can continue working in their own views.

Periodically, the project manager sends an excerpt from the findmerge log to an individual developer, who executes the commands and monitors the results. (The developer can send the resulting log files back to the project manager, as confirmation of the merge activity.)

A merged version of an element includes changes from three development efforts: Release 1.0 bug fixing, minor enhancements, and new features (see the following figure).

A version tree with three branches is shown with two merge arrows. — Figure 1: Merging Baseline 1 changes into the major branch

The project manager verifies that no more merges are needed, by entering a findmerge command with the –whynot option:

% cleartool findmerge /vobs/monet /vobs/lipub -fversion /main/LATEST –whynot –print

  .
  .
No merge "/vobs/monet/src" [/main/major/4 already merged from /main/3]
No merge "/vobs/monet/src/opt.c" [/main/major/2 already merged from
/main/12]
  .
  .

The merge period ends when the project manager removes the lock on the major branch:

% cleartool unlock brtype:major@/vobs/monet brtype:major@/vobs/libpub
Unlocked branch type "major".
Unlocked branch type "major".