Integrating Changes 

Integration of changes from source to target workspace (workspaces are present in the same repository): The mechanism of applying the changes done in one workspace to another workspace is called integration of an activity.

Assume that a resource R1 is added to a workspace ‘dev’ in the context of an activity A1. This activity is checked in and integrated into workspace ‘cons’.  The first figure below shows the version graph of the resource when requested from the ‘dev’ workspace. Version 1 is shown as an active version in the workspace.

The second figure below shows the version graph of the resource when requested from the ‘Cons’ workspace. 'cons' is shown as the active workspace and version 1 created in dev is the active version there, too.

A checked-in activity can be integrated in several target workspaces. Each integration makes the changes done in the activity visible in the target workspace.

The following two figures show the steps of integrating a resource into another workspace.

A resource was added in the context of activity A in workspace dev and checked in.

Activity A was integrated into workspace cons. Note that workspace cons points to physically the same version as long as no new version is created in cons.