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.      User 1 checks out a resource.

       2.      User 2 checks out the same resource.

       3.      User 1 makes the changes and checks in the activity.

       4.      User 2 makes the changes and tries to check in the activity.

The figure below shows a check-in conflict.

User01 and 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.

For more information, see Resolving Check-In Conflicts.