Team Development with Visual Studio Team Foundation Server

You might need to resolve conflicts when merging changes between branches, getting
files into your workspace, or checking in new versions of files. There are three conflict
types:
• Version – The file has evolved along divergent paths. This could be the result of a
file edit, rename, delete, or undelete operation.
• File Name Collision – Two or more items are trying to occupy the same path.
• Local Overwrite – Only occurs during a get operation, if you are trying to
overwrite a local, editable file.
Most conflicts can be resolved automatically; version conflicts are the only conflict type
that might result in a manual merge operation. Manual merge is most common in the
following scenarios:
• A file has been edited in both branches, with changes to the same lines of code.
• A baseless merge is being conducted in which the branch file relationships are not
known to TFS.
The merge tool shows you the details for each conflict and allows you to choose which
change you want to keep in the final merged file. You can choose to keep the source
change or the destination change, integrate both changes, or manually modify the final
version by typing directly into the file.
After resolving every conflict in the file, save the final version as a pending change to be
checked into the target branch.
Be careful when merging because it is easy to make mistakes that may result in build
instability. After you have finished merging, compile the resulting source and run unit
tests to test for major breaks.
Additional Resources
• For more information about resolving conflicts, see “How to: Resolve Conflicts” at
http://msdn2.microsoft.com/en-us/library/ms181433(VS.80).aspx
Builds
• How to use TFS to perform Continuous Integration builds
How to Use TFS to Perform Continuous Integration Builds
To perform continuous integration and rebuild your project every time a file is checked
in, you need to use a Web service to trigger the build process. You subscribe the Web
service to check-in events so that the build is triggered each time someone checks in a
file. To trigger the build, you also need to use an appropriate build type that determines
what configuration is built, what post-build steps and tests are executed, what drop
location is used, and so on.