There are two potential problems here:
As part of the Merge calculation, the server determines that no changes have been made against the target file since the last time they were fully synchronized. Therefore, it is safe (in terms of TFS semantics) in any case to simply overwrite the target file.
Both branches have history entries, so the server declares the file in a state of conflict. Now the client can choose a resolution.
- You can choose to keep either the source or the target as it is.
- You can select manual merge in the customized tool.
- You can request AutoMerge (via tf resolve -auto: acceptmerge or the "Automatically merge all" button in the external dialog box or the "merge changes me" switch in the internal dialog box)
- If AutoMerge fails, you will be given the same options, except that AutoMerge will not be available.
You can not do anything on the situation number 1. It really should be safe if there is no serious, undamaged defect in the server code, corruption in the history database, or, most likely, your previous resolution options have abruptly introduced TFS into your true intentions. In the worst case scenario, you always have the ability to create and run tests against your pending merge before anything is verified.
As you can see, in situation No. 2 there are many wrinkles. It is not clear which step of the process you want to ban, if any. The good news is that when control is transferred to the client, you have a wide (and easily expanded) range of choices. Only the hard part is to make sure that you understand the consequences of each; admittedly, neither the user interface nor the documentation are fully understood on this account. Respond to more information about your problem as needed.