Although the default compare tool built in with Visual Studio/TFS is adequate, I find situations where third party solutions have automatically resolved situations that the default tool did not. I have used a variety of tools and prefer KDiff3, but WinMerge, Beyond Compare, and others are all great options.

After setting up Visual Studio to use a custom tool, it will automatically use it for both comparisons and merges without prompting you. The automatic calculation of conflicts on check-ins is still done on TFS. This means it may list a certain number of conflicts, but when you open them locally with your custom tool they may all be resolved automatically. It may seem like it’s an extra step, but if you were just using the built-in tool, you would have handle all of the conflicts.

Go to Tools -> Options from the main menu.

Then go to Source Control -> Visual Studio Team Foundation Server.

From here click on Configure User Tools button, which will bring up the following popup.

After clicking Add, you will be given the opportunity to provide information for using a custom merge and compare tool.

You can see from the drop down there are two choices that correspond to our tools. Third party tools use different command line arguments for specifying compare and merge operations, so we need to specify them separately.

  • For the extension textbox, enter “.*” without the quotes. This will use the tool you specify for all of the file types.
  • Select the operation for Compare or Merge.
  • In the Command textbox, click the ellipse button and find the executable to the third party utility you have installed.

You can see the right arrow is clicked in the figure above and it expands a help menu. This menu is specifying how Visual Studio will provide the files, options and information to the utility.

For this example I’m using KDiff3. The arguments I use for compare are:

    %1 –fname %6 %2  –fname %7

For the merge arguments, I use:

    %3 –fname %8 %2  –fname %7 %1 –fname %6 -o %4

Tools Used:

  • KDiff3 0.9.95
  • Visual Studio 2010 SP1
Merge Sign
Merge? No Problem!

By default, a Team Foundation Server (TFS) Team Project will have multiple check-out enabled. This means that the same file can be checked-out by more than one individual at the same time. This is actually a good thing in that blocking changes does not occur when different people need to access a file and one or more people are unavailable to undo their check-out.

Some people then get concerned with merge complications (a.k.a. merge hell). At the surface, merging may seem complex, but when broken down it should be fairly straightforward. The built in tool with Visual Studio for compare/merge and third party tools, like KDiff3 and WinMerge, all provide a great way to automatically detect changes in a file. Most of the time those changes are not on the same line and the merge is automatically handled. In the case where two or more people are changing the same line, method or functional piece of code, I would consider that it really isn’t a problem with merging. The team members need to find out why two people are working on the same thing.

Sometimes it may be that two different people recognized the same bug and fixed it. They may both see convoluted code and refactor it to be cleaner. In these types of situations the second person checking in that then sees a merge conflict should be able to easily identify what happened and either throw away their changes or overwrite the previous check-in. In the strictest sense, one could argue that the developer should open a bug and add it to the backlog, but the case of refactoring smelly code doesn’t really fit that model. Often times I will see sprints with a refactoring bucket and task, which means tracking this type of change isn’t easily predictable. Either way, these aren’t major areas of merge complications.

There are times where merging is not that simple, but I would argue that it’s usually a project management issue or an architectural issue at that point. Two people shouldn’t be actively developing the same feature, because that would mean there is a communication breakdown. In an agile environment, the team members should be communicating at least once a day and be aware of what others are working on completing. If the file in question contains so much code that multiple people are inadvertently effecting each other, the code may need to be refactored on a larger scale to remove tight coupling. It should follow a separation of concerns approach.

Conclusion

I find allowing multiple check outs to be more beneficial than not. When Alice forgets to undo a check-out before she leaves for the day and Bob needs to update some other portion of the file, he inevitably ends up with a couple choices that all reduce his productiveness. He can move on to something else, forcing a context-switch in which he’ll have to return to when the file is available. He could find an administrator and have Alice’s check-out undone, which would leave Alice to handle a merge situation anyway with her local changes and whatever Bob checks in. Worst of all, Bob could have no other work to do and he ends up doing nothing productive.