Merge a change set with a gap in its history

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.
   
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.
   

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.

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 content conflict in the Gap editor is similar to resolving a content conflict resulting from an accept operation.

1. In the Gap editor, double-click the change to open a compare editor. In the following example, the file has a test method that was added in the gap and then modified in the change that you are merging.
   
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.

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.

1. Double-click a resulting change to open a compare editor. Inspect any text changes.
   
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.
   

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.

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

1. Accept the five change sets for task 1 into the 3.0.1.1 workspace.
   
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.
   
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.
   
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.
   
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.
    
    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.
    
    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.
    

Verify that the correct changes were backported.

1. Open the Locate Change Set editor from the work item with the original change sets.
   
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.
   
3. To view which changes sets are included and which are not included, hover over the pie icon in the search result entry.