Show TOC

Resolving ConflictsLocate this document in the navigation structure

Use

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.

Example

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.

Example

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.

Figure 1: The local version is removed in favor of the active version
Procedure

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:

    1. Choose Start of the navigation path Resolve Conflict Next navigation step Merge... End of the navigation path

    2. Create a new activity or select one from the list of existing open activities.

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

    4. Save the merged changes of to the newly created version.

      Note

      For more information about using external tools, see Setting Preferences of the Design Time Repository .

  • To merge the conflicting versions automatically, choose Start of the navigation path Resolve Conflict Next navigation step Auto Merge... End of the navigation path

    1. Create a new activity or select one from the list of existing open activities.

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

    3. Save the merged changes to the newly created version.

      Note

      For more information about using external tools, see Setting Preferences of the Design Time Repository .

  • To accept the conflicting version, choose Start of the navigation path Resolve Conflict Next navigation step Accept Active Version. End of the navigation path

    1. Create a new activity or select one from the list of existing open activities.

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

    3. Check in the activity. Checking in the activity resolves the collision between the two versions.

  • To accept the active version, choose Start of the navigation path Resolve Conflict Next navigation step Accept Coliding End of the navigation path.

    1. Create a new activity or select one from the list of existing open activities.

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

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

Result

Checking in the activity to DTR solves the conflict between the two versions and determines the active version in the workspace.