Show TOC

ConflictsLocate this document in the navigation structure

Use

When more than one user tries to modify the same resource in the same workspace, a checked-out version is created for each of these users. The new versions thus created receives a sequence number one higher than the last version of the resource that was created in the current workspace. So several checked-out versions are created in the same branch with an identical sequence number (however, a controlled management of the versions is guaranteed by the individual IDs).

There are different types of conflicts (also called collisions ) that may occur:

  • Check-in conflicts

    These occur during check in. A check-in collision happens when two users check out the same resource (for example, a.java ) from the same workspace and both try to check in their activities. The second check-in then fails because a new version of the a.java already exists in the workspace and this version is not a predecessor of the version created in the second activity. The Design Time Repository (DTR) automatically recognizes such check-in conflicts and prevents the second check-in , because this would mean that the changes made by the user who first checked in his or her changes would be lost.

  • Integration conflicts

    These occur when there are integrations of resources between different workspaces. Another situation where a collision can occur is when an activity is integrated into another workspace. The version that is being integrated is neither a predecessor nor a successor of the current active version in the target workspace.

Check-In Conflicts

The following happens:

  1. User1 checks out a resource.

  2. User2 checks out the same resource.

  3. User1 makes the changes and checks in an activity.

  4. User2 makes the changes and tries to check in another activity.

The figure below shows a check-in conflict:

User1 and User2 have concurrently checked out file F1 in the same workspace and created the appropriate activities. User1 has checked in activity A . It is now closed and version F2 is available in the repository (straight line). Version F2' of User2 is still open (hatched line). When User2 tries to check in activity B , the DTR recognizes the conflict ( F2' is neither predecessor nor successor of F2 , so it is not clear which version is meant to be active) and reports it.

Note

The icon Checked-out by another user, e.g. for file occurs on the resource and depicts that the resource has been checked out by another user. In this case, you can still check out the resource, as long as you do not check it out exclusively.

You can view a graphical preview of the versions of a certain file in the Design Time Repository perspective Version Graph view.

Integration Conflicts

The following figure shows an integration conflict:

A resource MyClass.java is created in workspace WS_a as version a1 and changed so that versions a2 and a3 are generated. In addition, it is integrated into workspace WS_b (still, the same physical file is used) and again changed: b1 and b2 are created.

Integrating version a3 in workspace WS_b triggers a conflict, because a3 and b2 are versions of the same file MyClass.java , but neither a predecessor nor a successor of one another: it is not clear which version is meant to be active in WS_b .

Integration Conflict Example

In the cons workspace the resource R1 is modified and a new version is created there. The figure shows the version graph of the resource:

A resource was modified in workspace cons

The same resource is also modified in workspace dev in the context of an activity A2 . The figure shows the version graph of the resource.

A resource was modified in workspace dev in the context of activity A2

When you integrate activity A2 in workspace cons , the DTR tries to integrate version 2 of resource R1 , which was created in workspace dev , into workspace cons . In this case, the DTR detects an integration conflict. This is a conflict because the version being integrated is neither a predecessor nor a successor of the currently active version (version 1 ) in workspace cons :

The figure shows an integration conflict

Since the integration is done across workspaces, any such conflicts that occur are automatically detected and stored in the DTR. The Design Time Repository perspective shows these conflicts in the Integration Conflicts view.