metro-problem-icon

If you are moving source from one team project to another (I am doing a migration of Source Code from “TeamProjectA” to “TeamProjectBTeamProjectA” in the same collection) you can get a TF14009 if there is a bad check-in in TFS from a previous version. In this case  a folder was branched from itself into a sub folder.

image
Figure: TF14009: Cannot merge source into target because the target is underneath source

Here is the full error message:

Figure: Error log of TF14009

Applies to

  • TFS Integration Platform
  • Visual Studio 2012 Team Foundation Server (from TFS 2008 upgrade)

Findings

Looking at the actual check-in it looks like both a Branch and an Add was performed at the same time in TFS 2008. This may have been Pre-SP1 where many of these issues were fixed, but it is still biting me now.

image
Figure: Changeset and Branch relationships

There does not seams to be an easy solution to this one…

It appears that the customer was a able to pended the new branch and renamed the source branch in the same changeset! This should have been caught by TFS’s internal checks that guard against  getting the system into this state. The Integration Platform may be trying to perform these actions in a different order and thus hitting the TFS 2012 rules.

As the system should not be able to get into this state, I am not sure we want to try and force this branch to be migrated to the target server the same way it is on the source server.

Depending on the requirements of the migration, we could try to:

  1. Cloak this path from this particular migration session
  2. Destroy the problem branch (if it is a dead branch, that was not used, for instance)
  3. Attempt to have the migration tool pend the changes in a different order to get the check-in by TFS (target system would then have this unexpected state)

I would not recommend #3, and #2 removes the data from the Source system. In this case I would go with #1.

Workaround #1

You can change the mappings while the migration is running by manually changing the XML. The UI will not let you do it as this is an advanced option but if you go to “Edit Current | Xml” you can add the mapping manually.

image
Figure: Manually adding a cloak to a run

Find your filter pair mappings and add one for that path that says Neglect=”true”.  Once you swap back to the “Form” tab you should see the new mapping and when you restart the migration the engine will detect the configuration change and will flush all pending migration instructions.

However in my case we had gone too far down the “Resolve” route and we needed to start over. To do that you need to call “tf destroy” to remove the half migrated data from source control and then create a new run with the Cloak already added.

image
Figure: UI with the Cloak added

Run again and you will then get your source across. If you want you can then manually move that cloaked folder to complete the data and with it no longer being a branch, our target system is then in a working state.

Did this help you?

-Every company deserves working software that successfully and consistently meets their customers needs on a regular cadence. We can help you get working software with continuous feedback so that your lean-agile teams can deliver continuous value with Visual Studio ALM, Team Foundation Server & Scrum. We have experts on hand to help improve your process and deliver more value at higher quality.

Tagged with →