TFS Integration Tools - Issue: TF14009: Cannot merge source into target because the target is underneath source

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.

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

Here is the full error message:

 1Microsoft.TeamFoundation.Migration.Toolkit.VersionControlMigrationException: Unable to pend the df249d50-fa3f-466f-b2e5-247ff0592911 action to $/TeamProject1/Folder1/Folder2 ---> Microsoft.TeamFoundation.VersionControl.Client.CannotMergeUnderSourceException: TF14009: Cannot merge source '$/TeamProject1/Folder1' into target 'TeamProject1/Folder1/Folder2' because the target is underneath source. ---> System.Web.Services.Protocols.SoapException: TF14009: Cannot merge source 'TeamProject1/Folder1' into target 'TeamProject1/Folder1/Folder2' because the target is underneath source.
 2--- End of inner exception stack trace ---
 3at Microsoft.TeamFoundation.Client.Channels.TfsHttpClientBase.HandleReply(TfsClientOperation operation, TfsMessage message, Object[]& outputs)
 4at Microsoft.TeamFoundation.Client.Channels.TfsHttpClientBase.Invoke(TfsClientOperation operation, Object[] parameters, TimeSpan timeout, Object[]& outputs)
 5at Microsoft.TeamFoundation.Client.Channels.TfsHttpClientBase.Invoke(TfsClientOperation operation, Object[] parameters, Object[]& outputs)
 6at Microsoft.TeamFoundation.VersionControl.Client.Repository4.Merge(String workspaceName, String workspaceOwner, ItemSpec source, ItemSpec target, VersionSpec from, VersionSpec to, LockLevel lockLevel, Int32 optionsEx, String[] itemPropertyFilters, String[] itemAttributeFilters, Failure[]& failures, Conflict[]& conflicts, Int32& changePendedFlags)
 7at Microsoft.TeamFoundation.VersionControl.Client.WebServiceLayer.Merge(String workspaceName, String workspaceOwner, ItemSpec source, ItemSpec target, VersionSpec from, VersionSpec to, LockLevel lockLevel, Int32 optionsEx, Failure[]& failures, Conflict[]& conflicts, String[] itemAttributeFilters, String[] itemPropertyFilters, Int32& flags)
 8at Microsoft.TeamFoundation.VersionControl.Client.WebServiceLayerLocalWorkspaces.Merge(String workspaceName, String workspaceOwner, ItemSpec source, ItemSpec target, VersionSpec from, VersionSpec to, LockLevel lockLevel, Int32 optionsEx, Failure[]& failures, Conflict[]& conflicts, String[] itemAttributeFilters, String[] itemPropertyFilters, Int32& flags)
 9at Microsoft.TeamFoundation.VersionControl.Client.Client.Merge(Workspace workspace, ItemSpec sourceSpec, String target, VersionSpec versionFrom, VersionSpec versionTo, LockLevel lockLevel, MergeOptionsEx mergeOptions, String[] itemAttributeFilters, String[] itemPropertyFilters, Int32 operationId)
10at Microsoft.TeamFoundation.VersionControl.Client.Workspace.Merge(ItemSpec source, String targetPath, VersionSpec versionFrom, VersionSpec versionTo, LockLevel lockLevel, MergeOptionsEx mergeOptions, String[] itemAttributeFilters, String[] itemPropertyFilters)
11at Microsoft.TeamFoundation.VersionControl.Client.Workspace.Merge(ItemSpec source, String targetPath, VersionSpec versionFrom, VersionSpec versionTo, LockLevel lockLevel, MergeOptionsEx mergeOptions, String[] itemAttributeFilters)
12at Microsoft.TeamFoundation.VersionControl.Client.Workspace.Merge(ItemSpec source, String targetPath, VersionSpec versionFrom, VersionSpec versionTo, LockLevel lockLevel, MergeOptionsEx mergeOptions)
13at Microsoft.TeamFoundation.VersionControl.Client.Workspace.Merge(String sourcePath, String targetPath, VersionSpec versionFrom, VersionSpec versionTo, LockLevel lockLevel, RecursionType recursion, MergeOptionsEx mergeOptions)
14at Microsoft.TeamFoundation.VersionControl.Client.Workspace.Merge(String sourcePath, String targetPath, VersionSpec versionFrom, VersionSpec versionTo, LockLevel lockLevel, RecursionType recursion, MergeOptions mergeOptions)
15at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.BatchingContext.pendBranches()
16--- End of inner exception stack trace ---
17at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.TfsVCMigrationProvider.SingleItemError(Object sender, BatchedItemEventArgs e)
18at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.BatchingContext.OnBatchedItemError(BatchedItem item, Exception exception)
19at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.BatchingContext.pendBranches()
20at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.BatchingContext.pendChanges()
21at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.BatchingContext.Flush()
22at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.TfsVCMigrationProvider.Flush(BatchingContext context)
23at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.TfsVCMigrationProvider.ProcessChangeGroup(ChangeGroup group)

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.

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:

Cloak this path from this particular migration session
Destroy the problem branch (if it is a dead branch, that was not used, for instance)
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.

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.

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?

Our Happy Clients

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.