Partager via

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

  • Article

I recently had to work with a customer to get them past a problem they encountered after performing a merge operation. The interesting part is that the issue was not necessarily in merge but rather when attempting to check-in; which shed some light on how good we need to be end-to-end sfor the customer to get the best experience with the product.

 

Note: On this blog post I am assuming that you are familiar with merge, resolve and some of our Version Control concepts so I will not go into detail about each of them.

 

The scenario is as follow:

1. Developer establishes a branch relationship between source and target (tf branch source target)

2. Normal development continues to happen and files get added and merged between these two trees

3. Developer deletes a file in source (a.txt)

4. Developer adds a file in source with that same name (a.txt) at a later time

5. Developer merges these files using the UI (you can also use the command line- tf merge source target /recursive)

6. Merge computes and for the file that was deleted and re-added a merge, branch is generated (this is expected)

7. Developer goes and checks in

8. Developer gets a conflict

9. Developer tries to resolve the FileName Collision conflict

 

And here is where he hit the problem. The only two options you can select from the resolve dialog are: Undo or Ignore. Guess what, none of them get you closer to actually resolving the conflict so now you are stuck (and yes maybe a bit mad at me and Microsoft).

 

How can you resolve this conflict you might ask? Well, the first thing is to undo those pending changes and really think about what you are trying to accomplish. I divide this into two main buckets:

a) The file was added by mistake and the developer should have really undeleted the file and then check-in a new copy. I need to establish the relationship again

b) The new a.txt is really another file and I need the target a.txt to take a new name

 

As you might expect each has a different resolution and cause so I will focus today on A: Establishing the relationship again and merging the contents.

To perform the baseless merge execute the following command from the command line:

 tf merge /baseless source/a.txt target/a.txt [/version:ChangesetNumber if wanted] /recursive

 

This will generate a conflict which you can resolve by running:

tf resolve /auto:AcceptYours (if you just want to keep what the target currently has because they are already in sync)

tf resolve /auto:AcceptTheirs (if you want to force the contents of source into the target)

                tf resolve (if you want to start the GUi and merge the changes manually)

 After the resolution is recorded you can check in and everything should be back to normal.

 

Hopefully this has helped you and over the coming days I will post a similar kind of step by step solution for the remaining two scenarios.

  

End quote: "One more to go"

Comments

  • Anonymous
    August 28, 2006
    The Visual Studio Team System User Education blog on New Team Build Customization Content on MSDN....
  • Anonymous
    August 28, 2006
    Mickey Gousset just published on the Team System Rocks blog a new VSTS Links Compilation. Lots of good...
  • Anonymous
    February 26, 2008
    I've recently had the exact error, and could not figure out why. It has taken some time to discover that a few people, in their wisdom (mad panic before a release), created a number of folders and files on two different branches, and checked them in separately. That is what caused our pain. The basic rule here, for us, is that if two items (folder or file) exist with the same name in two branches, but have no branch history, then they are distinct. TFS, quite rightly IMHO, sees this as a conflict because it assumes the people who created the files did not know that the other person created the same filename. Things TFS merge could do better:
  1. Determine that the file was checked in by the same person on both branches, and is therefore safe to assume they can be merged (so create a merge history).
  2. Compare the files, and if they are identical, assume human error and allow a merge. Thank you for the baseless merge instruction, which I knew of, but did not fully understand why it was necessary. Now I do. Thanks again Bernhard
  • Anonymous
    April 23, 2008
    The real problem is when you have folder conflicts and the folders are not empty. There is no way, that I know of, to handle that case. Running tf resolve /auto:AcceptTheirs will only prompt you that the folder (target) cannot be deleted because it is not empty. Well I know that, I just want to establish the relationship between the source and target folder. I don't even care who gets the upper hand in the parent child game. Martin