views:

27

answers:

1

In our case we want to igonore changes in code comment headers for generated code. In Visual Studio, we can change the merge tool (GUI that pops up) and use a 3rd party tool that is able to be customized to ignore changes (http://msdn.microsoft.com/en-us/library/ms181446.aspx). Great, so a file comparison no longer highlights code comments as differences.

However when it comes time to checkin, the TFS merge algorith is still prompting us to resolve conflicts.

Is there any way to better inform the merge conflict resolution algorithm about which changes are actually important to us? Or can we replace the algorithm or otherwise have it subcontract its work to a 3rd party?

+2  A: 

No. But this is actually a good answer for your scenario. When TFS blocks a checkin, it's not because it's running a diff of any kind: it's because your local version # doesn't match the latest version #. In other words, somebody else checked in the interim since you last ran Get + resolved file conflicts using your custom merge tool. Identifying these cases is a vital server-side feature that cannot and should not be disabled, since it cannot be reliably detected by any merge tool (including the one built into the TFS client API).

Back to why this is a good thing: once the conflict dialog comes up again, you're free to resolve the additional conflicts in your custom tool as normal. At no point is the built-in textual merge engine invoked.* The process is still entirely in your control. You'll still need to pick a "winner" [or generate a new one from the available inputs], even if the files are semantically identical according to your tool. But that's no different from any other Resolve scenario, such as ones you've apparently handled already.

*ok, I lied. It's used to generate the "X added, Y deleted..." summary you see in the dialog. Point is, it's not involved in identifying version conflicts, nor will it modify any files unless you ask it to ("merge changes for me").

Richard Berg