Since conflicts are resolved in the context of activities, the conflict resolutions can also be propagated or integrated into other workspaces. There are always two versions participating in a collision. One is the active version in the workspace. The other one is called the colliding version . There are three ways to resolve a collision. Depending on the origin of a collision (check-in or integrate), these three options have the following effect:
Accept the current active version
In case of a check-in collision , the colliding version is simply deleted.
In case of an integratecollision , a discard relation is created in the direction from the colliding version to the active version.
Accept the colliding version:
In case of a check-in collision , the active version becomes a predecessor of the colliding version.
In case of an integrate collision , a discard relation is created in the direction from the active version to the colliding version.
Merge the active and the colliding version:
In case of a check-in collision , the active version becomes a predecessor of the colliding version, a merge tool is opened which merges the content of the two versions, and the content is saved into the colliding version.
In case of an integrate collision , a new version is created as a successor of both active and colliding versions, a merge tool is opened and the user merges the content of the two colliding versions. The content is saved in a new version.
There are three ways you can resolve a conflict:
Merge the two conflicting versions - you can manually or automatically perform such a merge of the content of these files. Another option (for example, for Web Dynpro files) is to use the S2x or the Model merge.
Accept the conflicting version - that is, you accept the foreign version, and your entire resource is overwritten by this foreign version.
Accept the active version - that is, you reject the whole colliding foreign version, and your version remains the active version of the resource in the current workspace.
Merging Colliding Versions
You merge the content of two colliding versions if you want to have the content of the two different version in the same files. For example, this is a possible option for two Java source files. Merging of two files is supported by the DTR.
When user2 tries to check in the activity, a check-in conflict is reported. To resolve this conflict, user2 can decide to merge the contents of the two conflicting versions: user2 gets an option to merge the changes of the active version (version 3) into the local version (version 3 of user2 ). The local version with the changes merged from the remote version forms the next higher version (version 4) for the resource in the workspace. The figure below shows version 4 as a merging result; version 4 contains the merged changes of both users.
Version 4 was initially created as a successor of version 2 in the workspace, but now a sequence number 4 is associated with the version. This reflects that it was merged with the contents of version 3. The arrow between the versions 2 and 4 is an edit merge arrow. It depicts that version 4 is a result of the merging of version 2 with its direct predecessor, version 3.
The following figure shows the resulting version graph:
The left side shows the active version 3 in the repository merged with the local version 3 of user2 in activity Y.
The right side shows activity Y checked in. The merged version 4 is the active version in the workspace now.
Accept Active (Local) Version
The version graph created for this case is identical to the one for merging the two conflicting versions. The only difference is that version 4 in this case is not the result of merging the two conflicting versions, but has exactly the contents of the local version of user2 .
Accept Active (Remote) Version
You choose this option if the changes in the local version of user2 are to be discarded in favor of the currently active version in the workspace. That is, you accept your version to be discarded.
In our example, if user2 accepts the currently active version in the repository, then version 3 checked out by user2 is unchecked out and hence all the modifications made by user2 in his or her local version are deleted and then overwritten by the contents of the head version of the resource in the workspace.
Open the Version Graph view and select the conflicting version you want to fix. From the context menu choose:
To merge the conflicting versions manually:
Choose
Create a new activity or select one from the list of existing open activities.
After you create/select an activity, a new version of the resource is created. The merge tool appears; you use it to merge the contents of the two conflicting versions.
Save the merged changes of to the newly created version.
For more information about using external tools, see Setting Preferences of the Design Time Repository .
To merge the conflicting versions automatically, choose
Create a new activity or select one from the list of existing open activities.
After you create/select an activity, a new version of the resource is created. The merge tool appears; you use it to merge the contents of the two conflicting versions.
Save the merged changes to the newly created version.
For more information about using external tools, see Setting Preferences of the Design Time Repository .
To accept the conflicting version, choose
Create a new activity or select one from the list of existing open activities.
After you select/create an activity, a new version is created for the resource in the current workspace with the contents of the active version.
Check in the activity. Checking in the activity resolves the collision between the two versions.
To accept the active version, choose
.Create a new activity or select one from the list of existing open activities.
After you select/create an activity, a new version is created for the resource in the current workspace with the contents of your local version.
Check in the activity. Checking in the activity resolves the collision between the two versions.
Resolving Conflicts in Multiple Workspaces
In the Integration Conflicts view, select the conflicts you want to resolve using multiple selection. You can select integration conflicts from different workspaces simultaneously. Open the context menu and choose method to resolve the conflict.
Checking in the activity to DTR solves the conflict between the two versions and determines the active version in the workspace.