Why does Filename collision exist in TFS

I have a scenario where I have one master branch and one dev branch that is taken from the master branch. The master branch contains some old versions of some dll:s which I have updated in my dev branch. Now when I try to merge my changes back from my dev branch to the master branch I get a "Filname Collision" conflict. Of course the file name will coll开发者_运维问答ide, I have updated the file and want to use my newer version. But for some reason I don't have take local as a resolution to the problem. All I can do i either take server, rename server or rename local. Why is that?

---

The issue is that you replaced the DLL instead of "changing" it, so the merge recognises that it is a completely separate entry in the filesystem and complains.

It's explained more fully here and here, including a resolution:

We cannot resolve this through the GUI so we will drop to the command line and resolve the conflict appropriately. Within resolve we have the ability to specify a new name for the target file- you can find all the options here. The option we will use is AcceptYoursRenameTheirs and in a namespace conflict it accepts the contents and name of your file (source) and renames their (target) file to a new name that is specified.

To accomplish this we will also need to use the /newname option. Here is the command you should execute:

tf resolve a.txt  /auto:AcceptYoursRenameTheirs  /newname:a-old.txt

After this command succeeds you will get two pending changes: 1) a merge, branch for the new a.txt into the target folder and 2) a rename of a.txt to a-old.txt in target. So after checking in these changes the merge relationship will look like: source/a.txt à target/a.txt just as you wanted it.

If instead, you would like the opposite to take place, meaning you need source/a.txt to map to a new name in the target folder then the command to execute would be:

tf resolve a.txt  /auto:AcceptMerge /newname:a-newname.txt

Consequently that would give you a merge relationship of source/a.txt -à target/a-newname.txt

With the conflict resolved the developer is now free to check in the changes brought by this merge.

---

Most of the times this happens if you delete a binary file in source control and add it later. so i think you are using the following workflow:

• delete current binary file in source control
• commit
• add new binary file in source control
• merge -> file collision because of the file delete operation tfs cannot create a relationship between the file and won't provide any solution to fix the problem.

my workflow looks like this (it's working most of the time):

• checkout current binary file in source control
• replace binaries in local filesystem
• commit the changed binary files
• merge -> should now detect the new binary version and now you should have your typical experience