Example of merging gaps in change set history

In the following example, the change sets being accepted are backported from a version 4.0 development stream to a 3.0.1.1 maintenance stream. The workspace named 3.0.1.x Workspace flows with the 3.0.1.1 stream.
Note: The example is demonstrated in the IBM® Rational® Team Concert® Eclipse client but the same workflow applies to the Rational Team Concert Client for Microsoft Visual Studio IDE.

Pending Changes view for 3.0.1.x Workspace

Merging a change set with a gap in its history

Merge a change set with a gap in its history

Procedure

  1. To backport a fix that is associated with task 6, open the work item and click the Links tab.
  2. Select the change set that was created by Evan; right-click and click Accept.
    Task 6: test failure.
  3. The fix depends on other changes that were made in the 4.0 stream, so the change set cannot be accepted because there is a gap in its history. In the Continue Accept window, click OK.
    Continue Accept window.

Results

In the Gap editor, the Changes to Merge section shows the changes from the source change set that need to be merged into the resulting change set. The Resulting Change Set section shows the new resulting change set.

Gap editor.

In the Changes to Merge section, the change set that is being backported contains two file changes, both of which have a gap in their history.

  • The SubcommandLauncher.java file has two change details, a content change and an encoding change, both of which can be resolved automatically. The changes for the file are marked as done in the Changes to Merge section and a corresponding change is checked in to the resulting change set.
  • The DaemonStartCmdTest.java file has only a content change, but this change cannot be resolved automatically, so there is no corresponding change in the resulting change set yet. The next section describes how to manually resolve this change.
Tip: To show only the remaining changes to merge, in the Changes to Merge section, in the upper right, click the Filter icon; then select the Show merges marked as done check box. To view only unmerged changes, clear the check box.

Resolving a conflict with a gap in its history

Resolving a content conflict in the Gap editor is similar to resolving a content conflict resulting from an accept operation.

About this task

Note: The conflicts that occur when you apply a change set with a gap differ from normal conflicts because the common ancestor is unknown. Instead, the before contents for the change with the gap are used as the ancestor for the comparison. In the three-pane Eclipse compare editor, outgoing changes are not shown, so you see only the incoming changes. Four-pane external merge tools, such as ClearCase Merge, KDiff3, can improve merging.

Procedure

  1. In the Gap editor, double-click the change to open a compare editor. In the example below, the file has a test method that was added in the gap and then modified in the change that you are merging.
    Compare window
  2. After you merge the conflict in the compare editor and save the changes, return to the Gap editor. After you save the changes in the compare editor, the change is automatically checked in to the resulting change set.
  3. Select the change and click Mark as Done to indicate that the change was merged.

Completing the resulting change set

After you merge all changes, inspect the changes in the resulting change set before you complete the backport operation. The Resulting Change Set section shows all the changes in the resulting change set.

Procedure

  1. Double-click a resulting change to open a compare editor. Inspect any text changes.
    Resulting Change Set section
  2. Click Complete.
  3. Optional: If you selected the option to create a change set link, you are prompted to complete the resulting change set. Click OK to link the new change to the original source change set.
    Complete Resulting Change Set window.

Results

The new outgoing change set has an overlay in the upper-right corner of its icon to indicate that the change set is linked to another change set.

Outgoing changes in Pending Changes view.

Accepting from the merge queue

A work item can have multiple change sets for the same component.

Procedure

  1. Accept the five change sets for task 1 into the 3.0.1.1 workspace.
    Five change sets for task 1.
  2. A gap is encountered, so you proceed to the Gap editor.
  3. All the changes merge automatically.
  4. After you review each change, you notice that only one change has a gap. When changes do not have gaps or conflicts, they can be applied as they are, which preserves the state, or version, identifiers. This action increases the likelihood that subsequent change sets are accepted without gaps in their history.
  5. Inspect the change in the resulting change set that corresponds to the file with the gap to ensure that the merge occurred properly.
    Resulting change sets.
  6. In the editor, click the Merge Queue tab to view the Merge Queue page. Because the first change set that was accepted had a gap, the other change sets were added to the Merge Queue. These change sets can be reaccepted after the change set currently being merged is completed.
    Merge Queue.
  7. After you inspect the resulting change set, click Complete.
  8. To confirm the completion of the current merge and the creation of the link, click Yes.
  9. In the Complete Resulting Change Set window, select Continue accepting change sets from the merge queue after completion and click OK. One of the change sets accepts cleanly without a gap and the next change set includes the comment Merges.
    Resulting Change Set section.
  10. This change set is a merge of other work that occurred in version 4.0 and is not applicable to 3.0.1.1. In the Resulting Change Set section of the Gap editor, click Discard. You are prompted to discard the change set or add it back to the merge queue set list to be reaccepted later.
  11. To discard this change set, click Discard.
    Discard prompt.
    After you discard the change set, no source change set is listed in the editor, so the text in the Changes to Merge section indicates that there are more changes to accept from the merge queue. You can either click the links to initiate the accept operation or view the list of change sets in the merge queue.
  12. Initiate the accept operation, which results in the final change set being accepted without any gaps.
    Changes to Merge section.
    The final result of this backport operation is that two change sets had gaps and required a new change set to be created, while two others were accepted automatically, which results in the following change sets in the Pending Changes view.
  13. Deliver the changes to the 3.0.1.1 stream.
    Outgoing changes in Pending Changes view.

Locating change sets

Verify that the correct changes were backported.

Procedure

  1. Open the Locate Change Set editor from the work item with the original change sets.
    Locate Change Sets section.
  2. Search against the 3.0.1.1 stream. The result indicates that two of the change sets are included directly and two others are included indirectly by change set links. The fifth change set was discarded because it was not applicable to the backport operation.
    Search targets section.
  3. To view which changes sets are included and which are not included, hover over the pie icon in the search result entry.
    Search result entry.

Exploring change sets

Starting the Related Artifacts > Open Related Change Sets menu action on a set of change sets that contain links opens the Change Explorer view in a mode that shows the original change sets and any change sets that are related to that change set through change set links.

Change Explorer view


video icon Video

Jazz.net channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community

Jazz.net
Jazz.net forums
Jazz.net library

support icon Support

IBM Support Community
Deployment wiki