Modification of a Resource by Multiple Users 

Take an example where we have two users, ‘user1’ and ‘user2’ trying to modify the same resource in the same workspace ‘dev’.

The following figure shows the version graph as seen by ‘user 1’ after the resource is checked out for modification by the same user in the scope of an activity ‘X’.

Resource checked out by ‘user1’ in the scope of activity ‘X’

 

The following figure shows the version graph of the same workspace as seen by two different users. Version 2 is the current active version in the workspace. Version 3 in Activity X or in Activity Y, respectively, is the current working version for the respective user.

 

The figure on the left side shows the version graph as ‘user1’ sees it after ‘user2’ checked out the resource. Version 2 is the current active version in the workspace. Version 3 in activity X is the current working version for ‘user1’.

The figure on the right side shows the version graph as ‘user2’ sees he or she checked out the resource. Version 2 is the current active version in the workspace. Version 3 in activity Y is the current working version for ‘user2’.

 

Now activity X is checked in by ‘user 1’.

The following figure shows the resulting version graph as seen by the two users.

The figure on the left side shows the version graph as ‘user1’ sees it after he or she checked in the resource. Version 3 is the current active version in the workspace. Version 3 in Activity Y is the version checked out by ‘user2’.

The figure on the right side shows the version graph as ‘user2’ sees it after ‘user1’ checked in the resource. Version 3 is the current active version in the workspace. The version 3 in Activity Y is the current working version for ‘user2’.

 

Now when ‘user2’ tries to check in activity ‘Y’, a check-in conflict is reported. A conflict occurs between any two versions of a resource with a common predecessor when the version being checked in or integrated is not a predecessor or successor of the currently active version in the workspace.

There needn't exist a direct common predecessor of the conflicting versions. Conflicts are always detected. 

In the DTR, there are two possible types of conflicts – check-in conflict and integrate conflict.

...

       1.      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. The currently active version is called the ‘Remote’ or the ‘Active’ version. The version being checked in is called the ‘Local’ or the ‘Conflicting’ version.

       2.      An integrate conflict occurs when you try to integrate an activity in order to make the contained version the active version of a workspace, while this workspace already contains a version of this file, which, however, is neither predecessor nor successor of the version in the activity.  For more information, see Distributed Development.