Rebase

Rules for Rebase

When performing a Rebase merge operation, follow these general rules:

• The target view must be a branching (variant), immediate child of the source view.
• The target view items should have branch on change set, and have been created using a pinned (not floating) configuration.
• The Rebase operation can use any configuration of the source view (tip, label, timestamp, or promotion state), called the Rebase point.
• The Rebase operation uses the tip (updatable) configuration of the target view.
• Items newly-shared to or re-pinned in the target view use the Rebase/Replicate point. That point is the configuration time of the item in the source view.

Rebase Example Scenario

This example shows a typical scenario where an activity (child, branch-all variant) view is created from a specific label, promotion state, or timestamp to support a specific bug fix or enhancement. After changes are made in parallel in the parent and the child, a Rebase is performed to propagate parent changes to the child view. This process is repeated until the child view is no longer needed.

1. An activity (child, branch-all variant) view is created from a specific label, promotion state, or timestamp to support a specific bug fix or enhancement.
2. Changes are made for the activity: modified files branch, new files are added, files are moved or renamed, and so on.
3. Changes are made in parallel in the parent view.
4. A Rebase is performed to propagate changes in the parent to the child view.
5. More changes occur in both views in parallel.
6. Another Rebase is performed to propagate new changes.

In this scenario, an activity view is rebased twice to update it with changes that occurred in the parent.