About the rebase operation

The rebase operation provides the way for developers on a UCM project to update work areas with work that has been integrated, tested, and approved for general use. This work is represented by baselines.

The work areas that are updated can be integration streams or development streams. The update reconfigures a stream by adding, dropping, or replacing one or more of the foundation baselines of the stream.

Any changes that are made in the stream before a rebase operation is performed are preserved during the rebase operation. For any file modified in the stream, any changes that are present in versions of that file in the new foundation baselines are merged into the latest version of that file in the stream, thereby creating a new version. All such merged versions are captured in the change set of an integration activity that the rebase operation creates. This integration activity becomes the current activity of the view until the rebase operation is completed or canceled.

If the operation finds a version whose element has a mergetype of user, you see a window in which you must choose the way to handle the version.

A rebase operation is performed in a view that is attached to the stream that is being rebased. No versions should be checked-out in that view. (For a single-stream project, the rebase operation skips the checked-out file and continues with other files.)

If you work on a multiple-stream project, it is recommended that you perform a rebase operation just before performing a deliver operation to reduce or eliminate the need for manual merging during the deliver operation.

You cannot perform a rebase operation when a deliver operation is in progress.

The project manager or integrator organizes delivered activities into baselines. Usually baselines go through a cycle of testing and bug fixing until they reach a satisfactory level of stability. When a baseline reaches this level, the project manager designates it as a recommended baseline.

If you work on a multiple-stream project, you rebase your work area to work with the set of versions in the recommended baseline. To minimize the amount of merging necessary while you deliver activities, rebase your work area with each new recommended baseline as it becomes available.

A development stream can be rebased to a baseline that meets the following criteria:

• The baseline was created in its parent stream.
• The baseline is in the foundation baseline of the parent stream.
• The baseline was created in a stream other than its parent stream and is contained in its parent stream. (A baseline is contained in another baseline if all changes in the first baseline are included in the second baseline.)

There are rules for reverting or dropping a baseline in a stream and for switching to a baseline that is neither an ancestor nor a descendant of the current foundation. These rules for baselines are enforced so that any changes made in a stream are not lost (stranded) when the configuration changes.

After the merges being performed during the rebase operation are complete, you see a merges complete window. Ensure that you build and test the source files in your development view to verify that your undelivered activities build successfully with the versions in the baseline. After you test your work, then complete the rebase operation (click Complete in the Rebase Status window). While any versions that are checked out to your development view are being checked in, the Rebase Status window remains open. When the development stream has been notified that the rebase operation is complete, the window closes.