Promote Merge

Use a Promote merge to “deliver” changes in a child view to its parent. You could promote once at the end of the child view’s lifecycle as a prelude to discontinuing work in the child view. However, you can also promote multiple times to periodically deliver changes from the child view to the parent. In either case, it is typically a good idea to rebase the child view just prior to promoting it to ensure it has “accepted” (been merged with) all recent changes from the parent view.

Back to top

Rules for Promote

When performing a Promote merge type, follow these general rules:

  • The source view must be a branching (variant), immediate child of the target view.
  • The Promote operation uses the tip (updatable) configuration of the target view.
  • The Promote operation can use any configuration of the source view (tip, label, timestamp, or promotion state).
  • New source items are reverse-shared to the target view. This means they are moved from the child to the parent and then shared back to the child with Branch-On-Change set, and with a pinned configuration. New items not promoted at the latest (tip) revision may be marked as merge conflicts in the child view.

Back to top

Promote Example Scenario

This example shows a typical scenario where the a child view is created to enable a new branch of development that is simultaneous with continued development on the main branch. During development, the child view is modified, rebased, compiled, tested, then ready for release. At various stages, changes from the child view are promoted to the parent view to release changes, perhaps at key delivery milestones. At the end of the branch's life, a Rebase is performed with the parent view. After the changes in the child from the parent view are compiled, the child view is promoted to the parent again.

  1. An "activity" view has been created, modified, rebased, compiled, tested, and is ready to be released.
  2. A Promote is performed to release child changes to the parent view.
  3. More changes are needed in the activity view.
  4. Meanwhile, the parent is also modified.
  5. A Rebase catches up the child with the parent.
  6. Compile and test are okay, so the child is promoted to the parent again.
  7. The activity view eventually becomes obsolete after that.

In this scenario, the child view is promoted twice and retired (no longer used) after the second promote. Typically, you’d want to delete a retired view after a period of time.

Back to top