Version conflicts arise when files are edited concurrently on the server and in your local workspace. For example, you check out a file readme.txt at changeset 42. Meanwhile, another user makes changes to the same file and checks the changes in, resulting in changeset 43. Since you have pending changes on the file and it is not the latest version on the server, you have a version conflict and you will be notified when you attempt to get the latest version or check in your changes. You will be required to resolve this conflict to proceed.
Merge conflicts are special types of version conflicts that arise when a common file is edited in two different branches. For example, a file $/One/readme.txt is branched to $/Two/readme.txt and each file has been modified. When you merge from $/One to $/Two, you will be required to resolve this conflict to proceed.
Filename conflicts arise when a file exists on the server and you attempt to add a file of the same name. For example, you pend an addition for the file readme.txt. Meanwhile, another user adds a file of the same name and checks the add in. You now have a filename conflict and you will be notified when you attempt to get the latest version or check in your changes. You will be required to resolve this conflict to proceed.
Filename merge conflicts are special types of filename conflicts that arise when a file of the same name is added in two different branches. For example, a directory $/One is branched to $/Two. Each directory has a file added named readme.txt. When you merge from $/One to $/Two, you will be required to resolve this conflict to proceed.
Writable file conflicts arise when files are made writable on the local filesystem without checking the file out. For example, you have a file readme.txt at changeset 42 and you set the file writable using the attrib command (Windows) or the chmod command (Unix). When you attempt to get the latest version, you will be required to resolve this conflict to proceed.
When you perform a get, check in or merge operation that leads to conflicts, you will be notified by the conflict notification dialog:
You may select a single conflict and select the Resolve button. This provides detailed information about the conflict, including comparisons between the local file, server file and their common ancestor, which should assist you in resolving the conflict.
You may also select multiple conflicts and select the Resolve button. This allows you to resolve multiple conflicts at once. This may allow for more efficient resolution of conflicts, but lacks the fine-grained control available with resolving a single conflict.
You may select Auto Merge All to attempt to use auto merge to resolve all conflicts. If any files have "conflicting content changes", that is, two orthogonal changes in the local and server versions of a file, then these conflicts will remain in the conflict list and must be resolved manually.
If you resolve all conflicts in this dialog, you may continue to perform the operation that led to these conflicts. However, if you close this dialog without resolving all conflicts, you must still resolve these conflicts before continuing.
You may select a single conflict and select "Resolve" to select a resolution option. You will be presented with conflict details and prompted to select a resolution option:
This dialog shows you the following information about the conflict:
Description: a textual description of the conflict, explaining the server item involved and what actions led to the conflict.
Local Path: the local path of the target of the conflict.
Changes: for version conflicts on non-binary files, this field displays the number of changed regions of the file. This is determined by a pass with a compare engine. Local changes are changes that you have made, server changes are changes that have been made on the version you are retrieving from the server. Common changes are identical changes on the local and server file. Conflicting changes are dissimilar changes made to the same region of the file.
The conflict resolution dialog offers a Compare... button which will allow you to compare the files leading to the conflict: the source of the conflict, the target of the conflict and the common ancestor, when applicable. Comparing can be very helpful in choosing a resolution option as it can show the actual changes leading to the conflict and may show whether automerge is appropriate for this conflict.
The actual compare options provided depend on the type of conflict, and are described in Microsoft's Understanding Conflict Types documentation.
The resolution option you select determines how the conflict will be resolved. The resolution options available to you depend on the type of conflict. For a list of available resolution options, please see Microsoft's Understanding Conflict Types documentation.
For version conflicts and merge conflicts, the "merge changes for me" option is available. This will perform an auto merge on the conflicting files if there are no conflicting content changes (noted in the "Changes" field.)
If you have an external merge tool configured for this type of file, the "merge using external merge tool" option is available.
Your resolution option is applied when you press OK. If you cancel this dialog, no resolution will be applied and the conflict will not be resolved. This conflict must still be resolved to continue your operation.
The resolution options available depend on the type of conflict. For a list of resolution options, please see Microsoft's Understanding Conflict Types documentation.
If you do not choose a resolution option for a particular group of conflicts, those conflicts will remain in the conflict list and must be resolved individually. Similarly, if any conflicts cannot be resolved, you will receive notification that resolution failed and those conflicts must be resolved manually.
Auto merge is a powerful merge technique which examines two changed files and their "common ancestor" to determine the independent changes to the file and produce an output that incorporates both sets of changes.
For example, consider a simple four-line text file, readme.txt and assume that you check this file out at changeset 42. You change the first line. Simultaneously, another user checks the file out, changes the third and fourth line and checks the file back in. If you were to auto merge the file, the result would include your changed first line, and the server version's changed third and fourth lines. Consider the following chart:
| Original Version | Latest Version | Your Changes | Merged Version |
|---|---|---|---|
| one | 1 | one | 1 |
| two | two | two | two |
| three | three | 3 | 3 |
| four | four | 4 | 4 |
Auto merge is not able to merge changes if you had both made different changes to the same line of the file. This is considered a "conflicting content change".
It is important to note that auto merge does not examine the content of the files, only the fact that lines have changed. One should still examine the merged output. For example, if one user removes a variable declaration, and your change depends on that variable, auto merge will dutifully remove the variable declaration and include your change which depends on that variable, however that will lead to a compile or runtime error.
Related Microsoft Team System Documentation:
Related Documentation:
Configuring a Merge Tool
Getting the latest version
Checking in files
Merging branches