It will contain all the changes.
Except that incremental baselines will calculate these changes by adding:
- unique modifications made to several changes (this is what the "incremental baseline" means: the label is set only in new versions from the previous baseline)
- all other changes already refer to previous baselines to the full baseline
See “ Baseline Types ”:
- A complete baseline is the baseline that you create by writing all versions of all elements under the root directory of the component.
- incremental baseline - the baseline that you create by recording the last complete baseline and those versions of elements that have been changed since the last complete baseline.
(there are also “baseline checkpoints,” as described in “ about ClearCase baselines ” that automatically create delivery and forwarding operations, but you don’t need to worry about it right now)
That's why I always prefer a full baseline: the whole delta operation (like “compare against another base”) is faster if your last baseline is complete.
The argument in favor of incremental baselines is that they are created faster (due to the fewer versions on which you can set the baseline).
But if your UCM component is so large that it’s too long to put a label on all its versions, your component may be too large.
Please note that you can always upgrade an incremental baseline to a full baseline.
Please note that you have a difference between:
- baseline header (here "
MYProj_2.0.0.20 ": you can put as many baseline " MYProj_2.0.0.20 " as you want) - base line identifier (always unique: if "
MYProj_2.0.0.20 " is already accepted, then ClearCase will generate some numbers at the end: " MYProj_2.0.0.20.345 2")