Resolving a Check-In Conflict 

There are three ways to resolve check-in conflicts:

·         Merging the active version with the conflicting version

·         Accepting the conflicting version

·         Accepting the active version

Merging the Colliding Versions

Use the option for merging the changes done in the active and conflicting versions to resolve the conflict between the two versions, if parts of both versions are needed. Merging two files is supported by the DTR.

In our example, when ‘user2’ tries to check in the activity, a check-in conflict is reported. To resolve this conflict, ‘user2’ can decides 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.

Accepting the Local (=Conflicting) 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’.

Accepting the Active Version

You chose this option if the changes in the local/conflicting version of ‘user2’ are to be discarded in favor of the currently active version in the workspace.

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 done by ‘user2’ in his/her local version are deleted and then overwritten by the contents of the head version of the resource in the workspace.

The local version is “unchecked out” in favor of the active version.