Gaps in change set history

You can accept a change set only if the target workspace has all the change sets that the change set being accepted depends on. If one or more of these change sets are missing, the change set cannot be accepted. This condition is referred to as a gap. If this condition occurs, you can merge the changes into a new change set. When you merge a change set that contains gaps, you can create a link between the source change set and new resulting change set to preserve traceability.

The underlying history model of Engineering Workflow Management source control requires that the history is graphed and that all paths lead back to the new file state for any file. The following example illustrates why it is important to trace history back to an initial state. In the example, change set CS3 is being accepted into a component that has change set CS1 in its history but is missing change set CS2. In this case, CS3 cannot be accepted as is because the change for file a.txt is missing its predecessor from CS2. This condition is a gap in the history of file a.txt because it is not possible to find a path from the a.txt change in CS3 back to the file creation.

The following line is the initial content for a.txt in CS1.

This line is introduced in CS1

CS2 adds a line and makes the content:

This line is introduced in CS1

This line is added in CS2 but not applicable everywhere

Finally, CS3 adds another line:

This line is introduced in CS1

This line is added in CS2 but is not applicable everywhere

This line is added in CS3 and everyone wants it

If CS3 was accepted into the history despite the gap, the a.txt file would have the above contents, including the unwanted content from CS2.

After CS3 is accepted on top of CS1, you want the following content, which includes the line from CS1 and CS3, but not the line from CS2.

This line is introduced in CS1

This line is added in CS3 and everyone wants it

When gaps occur in change set history

The following workflows can result in a gap in change set history:

  • Backporting bug fixes from a current release stream to a previous release stream. In this workflow, a bug fix is built on top of change sets that you do not want to backport.
  • Accepting change sets from a work item to review changes. Gaps occur less frequently in this workflow because the developer and the reviewer often work from the same stream; however, a gap can occur if the developer has other changes in a workspace that are not delivered to the stream.
  • Mixing and matching features in a build by accepting change sets from the corresponding work items. You can introduce an unwanted dependency between features, depending on the order in which features are created.

video icon Video channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community forums library

support icon Support

IBM Support Community
Deployment wiki