When a rename is checked in, the server paths for other workspaces’ pending adds and branches are updated according to the rename being checked in.  If the server cannot update one or more server paths in the pending adds or branches in other workspaces because it would cause two pending changes to reside at the same server path (the server allows only one pending change per target server path), the checkin fails with the error message, “TF14107: The changes could not be checked in due to an incompatible change in another workspace.”

This error is correctly triggered when someone else has an add or branch to a file by the same name.  Unfortunately, it’s also triggered by having another person unshelve your changes where you have renamed a file and added a new one with the original name (we ran into this internally).

The scenario that triggered the error message recently, and thus prevented the user from checking in, is the following.

1. User A pended a rename of RangeType.cs to RangeName.cs
2. User A pended an add of a new file called RangeType.cs (the same path as the original file on the server)
3. User A shelved the changes
4. User B unshelved the changes to build them as a verification step prior to User A checking in
5. User A attempted to check in and received the TF14107 error

In the scenario described above, the server incorrectly sees the pending add of RangeType.cs in the User B’s workspace as needing to be renamed to RangeName.cs as a result of checking in User A’s changes.  In this case, RangeType.cs is a pending add that has nothing to do with the rename, except that RangeType.cs was the original name of RangeName.cs.  The problem is a bug in the code that detects the condition for TF14107.

The work around is to undo the changes in the other workspace and then check in the rename.  To find the other change that is causing the problem, you will need to use the status command in tf.exe.  For example, running tf status /user:* $/Project/RangeType.cs $/Project/RangeName.cs would show all of the pending changes for all users on those files.  If you want to see the workspace(s) with the other changs, you can add the /format:detailed option.  In an emergency, you (or someone with UndoOther permission, such as the admin), could undo the change with tf undo /workspace:OtherUserWorkspace;OtherUser $/Project/RangeName.cs.

[Update 6/3/06]  I added info to the last paragraph regarding workspace info and undo.
[Update 3/15/06]  I removed a typo at the beginning.