I recently was asked why a client had experienced some unexpected results when merging a development branch back into the main trunk on a TFS 2010 installation.
Turns out the issue was that during some tests that the both the Main and Dev branches had been renamed, and new branches of the same names created. So they had a structure like this:
|Dev||Newly created after the rename|
|Main||Newly created after the rename|
|Old_Dev||Renamed of Dev|
|Old_Main||Renamed of Main|
In TFS 2010 behind the scenes a rename is actually a branch and delete process, this meant we ended up with the new branch, but also a deleted branch of the old name. This is not obvious unless you have ‘show deleted items in source control explorer’ enabled in the Visual Studio option
Once you recreate a new branch with the same name as one of the old named branches this deleted branch is replaced by the newly created one, It has taken up the old ‘slot’ (see links at end).This means that when you try to do a merge the merge tools sees this recreated branch as a potential target, and so shows it in the merge dialog. With all the potential confusion that might cause.
So the simple answer is try to avoid renames, and especially try to avoid creating new branches in the same ‘slot’ as deleted/renamed ones.
For a more detailed explanations of that is going on here have a look at this post on renaming branches in TFS and this one on ‘slot mode’ in 2010 version.