FileName Collision Conflict that won't resolve through the UI- Part 2 of 2

Hi guys:

Sorry it took so long to get this fourth blog in but we had a lot to do these past weeks so I had to cut back a bit. Without delay let’s return to the previous post and get set to handle case B: “The new a.txt is really another file and I need the target a.txt to take a new name”

Again, 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: https://msdn2.microsoft.com/en-us/library/6yw3tcdy.aspx . 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.

End Quote: "Not all of the deletion is being undeleted … what do you mean by that?"