TFS Integration Platform: '$\xxx\yyy' cannot be cloaked because it does not have a mapped parent - BUT IT DOES!
-
Tuesday, December 06, 2011 10:07 AM
Hi all, there is a very similar question to this one which has never been answered, so I'm posting it again. This has happened to me twice on two completely different projects so there is definitely something going on here. It seems to me that the integration platform is somehow trying to create the lower level mappings, before creating the root mapping. What is even stranger, is that when I run this config file on our test target it works, but when I run it on the live one it gives me a runtime conflict. In the example file below, this fails when going to the $/Direct target, but when I edited it to our $/DirectTest target it succeeds! I have tried all the obvious things (clearing all TFS cache folders, deleting older sessions etc)
Here is an example config snippet:
<Filters>
<FilterPair Neglect="false">
<FilterItem MigrationSourceUniqueId="a4f6e34c-802e-4e79-af6f-72067e854064" FilterString="$/Acme_Direct" SnapshotStartPoint="261409" MergeScope="$/Acme_Direct" />
<FilterItem MigrationSourceUniqueId="e09cbca4-cf28-4e53-863e-e091ba54a6b4" FilterString="$/Direct" MergeScope="$/Direct" />
</FilterPair>
<FilterPair Neglect="true">
<FilterItem MigrationSourceUniqueId="a4f6e34c-802e-4e79-af6f-72067e854064" FilterString="$/Acme_Direct/App/Dev/r6" />
<FilterItem MigrationSourceUniqueId="e09cbca4-cf28-4e53-863e-e091ba54a6b4" FilterString="$/Direct/App/Dev/r6" />
</FilterPair>
<FilterPair Neglect="true">
<FilterItem MigrationSourceUniqueId="a4f6e34c-802e-4e79-af6f-72067e854064" FilterString="$/Acme_Direct/App/Dev/r7" />
<FilterItem MigrationSourceUniqueId="e09cbca4-cf28-4e53-863e-e091ba54a6b4" FilterString="$/Direct/App/Dev/r7" />
</FilterPair>
<FilterPair Neglect="true">
<FilterItem MigrationSourceUniqueId="a4f6e34c-802e-4e79-af6f-72067e854064" FilterString="$/Acme_Direct/App/Dev/r6.5" />
<FilterItem MigrationSourceUniqueId="e09cbca4-cf28-4e53-863e-e091ba54a6b4" FilterString="$/Direct/App/Dev/r6.5" />
</FilterPair>
<FilterPair Neglect="true">
<FilterItem MigrationSourceUniqueId="a4f6e34c-802e-4e79-af6f-72067e854064" FilterString="$/Acme_Direct/App/Dev/r6.6" />
<FilterItem MigrationSourceUniqueId="e09cbca4-cf28-4e53-863e-e091ba54a6b4" FilterString="$/Direct/App/Dev/r6.6" />
</FilterPair>
</Filters>- Edited by zedhex1 Tuesday, December 06, 2011 10:08 AM
All Replies
-
Thursday, March 15, 2012 3:37 PMStill no reply on this?? It has been three months already.
-
Friday, March 16, 2012 2:33 PMModerator
Sorry for the lack of a reply.
The integration tools are formally supported by Microsoft support. I searched through open cases and found a related one. The symtoms described match your symptoms pretty closely - including the fact that it works differently on some systems. The support engineer found that the commit of the configuration data to the DB sometimes inverted the order of the filter pairs from what you see in the XML doc. They helped the customer work around the problem on the system exhibiting the problem by using the incorrect, reverse order in the XML doc.
Bill
-
Monday, March 19, 2012 2:13 PMModerator
A new release of the TFS Integration Tools was published last week. You will find it here. I've been told this bug has been fixed in that release.
Bill
- Marked As Answer by Bill Essary MSFTModerator Friday, March 23, 2012 3:14 PM

