TFS Integration Tools – Issue: TF10141 No Files checked in as a result of a TFS check-in failure

If you encounter a TFS check-in failure conflict type and you try the first option of “Retry the action”.

Figure: This conflict is generated during the final checkin.

The migration exists and you are left with some Purple columns in the UI.

Figure: Nice green UI covered with purple crap

This is followed by a strong sinking feeling after 14 hours of babysitting the migration… there are only 96 items left to go…

  • Update 2012-08-22 – I messed up on the final dialog… thanks to Jameson Miller for spotting this one.

Applies to

  • TFS Integration Tools (March 2012 Release)


Your first thought will be to click “Start” and run the migration again and it tells you that there are 96 items to be migrated.

Figure: Its going… its going…

After which you will be greeted with a “your migration was successful”, but don’t be fooled. This migration…. it is lying to you…

You need to look at the logs now, and low and behold:

Checkin failed – TF14080: The item ‘$/XXX XXXX/XXX/Version4_0-Next_Build/XXXAdmin/App_WebReferences/XXXXXXXWCF/Reference.svcmap’ has a pending merge / rollback conflict, run resolve before checking in.

To start moving forward we need to move back… delete the rule (“View Conflicts | View Rules”) and click “Start” again.

Figure: Delete this rule that you just added

And we end up back at the conflict resolution screen, but now armed with the knowledge that “Retry this action” is not going to work.

Figure: See… back to the start…

Now we need to specifically solve the problem and this problem is a gnarly one. We need to look at what is currently pending in TFS.

Figure: Figure out what is conflicting

Now while you can do this from the command line that is something that I am not comfortable with (sorry… not old enough Smile) but I can open TFS under that user account and resolve the conflict…

Figure: TFS Sidekicks to save the day.

If like me you are command line adverse, then you can install the Team Foundation Sidekicks along with the TFS 2010 API and gain access to the data that you are looking for. In this case it also tells me the Workspace that I need to load…

Figure: Load the offending workspace

Now we need to figure out the problem. To do that we need to look at the offending change and manually resolve the conflicts.


Figure: Woops they are not the same

This is an issue as the change from the original files is not replicated correctly. This could indeed be a big in TFS, the TFS Integration Platform or both but that small comfort does not help me now…


To move past this we need to manually resolve the conflicts and check-in. We can then take the original source check-in and along with the new target changeset resolve the conflict in the Integration Platform.

Figure: Resolution causes TF14092

Attempting to resolve the conflict in favour of the source by clicking “Take Source Branch Version” runs into the same problem that the TFS Integration Platform likely ran into when it was trying to achieve the same result.

Resolution causes TF14092: The item $/XXX/ cannot be changed. A parent of this item has a pending delete which must be checked in first.

This to me looks like it was because of the order that VC committed items  in TFS 2008 and how it is now committed in TFS 2012. If that is the case then the argument for which service the bug is in could be made either way…

However clicking “Take Target Brach Version” results in a successful merge but will leave those files in source control after the operation. I can however keep track of this additive data and resolve it permanently by deleting them as part of a clean up at the end..

Figure: Use the following changesets for the source and target system

Now that I have manually resolved the issue I can go back to my conflict in the TFS Integration Platform and manually wire up the source check-in to the target one that I just manually checked in…


In the context of this Conflict the Source does not refer to the Migration Source as you would think. It relates to the Source of the Conflict instead and in this case it is the “Migration Target”. So the source is the Migration Target and the Target is the Migration Source… and are we confused yet, coz I was!

Reference: TFS Integration Tools – VC Conflict “A namespace conflict has been detected” … what now?

After Jameson pointed this out to me I was muttering like a Pirate that has stubbed his toes for at least an hour…


Did this solve your conflict?

  • Pingback: TFS Integration Tools - Issue: Unable to resolve conflict as Access to the path is denied - Visual Studio ALM from Martin Hinshelwood()

  • Bin Wan

    Hi Martin,
    We encounter the same type of conflict when moving team project from one account to another in VSTS.
    How do you open the resolve conflicts window in VS? On target system I didn’t see any conflict in VS after getting latest code.


    • Bin, unfortunately the TFS Integration tools are not supported in VSTS and can cause damage. I would recommend that you use Git-TFS instead and move your repo to Git, much higher fidelity.

      • Bin Wan

        Hi Martin, our project needs to be used TFVC version control and CMMI work item process. Is there any way to move it? Thanks

        • I’m not sure what TFVC & the CMMI template give you but they certainly are not “required” for any process in any organisation. It’s fine to choose them if you want, but they are never required.

          There is no way to move with history from one TFVC location to another. The TFS Integration tools only replay your history and do not capture it. The only way to preserve the history and timeline is to move to git which supports that kind of history migration and building.

          If your insist on TFVC then I would recommend a branch tip migration. Move each branch without history. You can always refer back to the old project which would satisfy any audit.

          Can you share why you need to move? Happy to also email…

          • Bin Wan

            The Microsoft Dynamic 365 for Operation(AX7) requires TFVC and CMMI. The reason we want to move is regarding to subscription and license problem.

          • I take it back, for AX you need TFVC, but what is the work item dependancy?

            You will likoey need to move without history. But you can move with branchs.

          • Bin Wan

            No sure about the work item dependancy.
            You mention using TFS Integration tool can cause damage. What damage can it cause?

          • As per versions of TFS beyond 2012 are explicitly not supported. I have had it damage both source control and work item tracking in the past. Generally a “destroy” fixes source code, but WIT can be a bigger problem requiring the intervention of the product team. You will not be able to break wit on VSTS because you will not be able to bypass the rules, which is where the damage occurs.

            The TFS IP bypasses the rules by communicating directly with the web services, which have changed since the last time it was supported. This is where the majority of problems can occur.

            I built tools for migrating work items that are supported. But I focus on work items since there are plenty of tools for migrating to Git.

            If you are migrating TFVC to TFVc I recommend that you do branch tip migrations manually. Then migrate work items separately using my tool

          • Bin Wan

            thank you Martin for your suggestion.