Check-In Conflicts 

When you develop concurrently and then try to check in your changes, conflicts can occur. The Design Time Repository (DTR) automatically recognizes such check-in conflicts.

A check-in conflict occurs when the version that is being checked in is not a direct successor of the currently active version in the workspace. This can happen in the following case:

...

       1.      User01 checks out a resource.

       2.      User02 checks out the same resource.

       3.      User01 makes the changes and checks in the activity.

       4.      User02 makes the changes and tries to check in the activity.

The figure below shows a check-in conflict:

User01and User02 have concurrently checked out file F1 in the same workspace and created the appropriate activities. User01 has checked in activity A. It is now closed and version F2 is available in the repository (straight line). Version F2’ of User02 is still open (hatched line). When User02 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.

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. For more information, see Modifying a Versioned Resource.

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

For information about how to resolve conflicts, see Resolving a Check-In Conflict.