TFS Migration Errors

January 2007 - Ah one month down in our Team Foundation Server (TFS) implementation! We've actually been quit busy even though upper management might not think so. Little do they know, while we wait for our PROD hardware to arrive we've had a demo copy running for months on some antiquated hardware we found under old C++ programming guides.

This past month we've been concentrating on designing workitem types for our CMMI process improvement implementation that we're so proud of, and spent a lot of time doing test migrations from Visual Source Safe (VSS) to TFS. It's in the VSS to TFS migration spirit we'd like to concentrate this month's post on. We've run (actually more like stumbled) into some valuable information that we're hopeful future (or current) TFS users will find valuable.

First some statistics from the VSSConverter tool. So far we've migrated 55,389 files with 137,547 "actions" in around 7 hours and 45 minutes running on desktop machine (996 MHz processor with 512 Mb of RAM). From what we can gather an "action" is any history item (e.g. edit or add) in VSS. We feel this is pretty acceptable and have no issues with the migration duration.

Now onto the errors and warnings. During our test migrations of VSS to TFS we've run into multiple instances of the following errors and would like to share our observations and thoughts of why the errors might have happened. Now I'm skeptical of most hypothesis, including the ones I come up with. So take this as is, and feel free to provide feedback if you agree or differ with our findings.

Error/Warning 1:
"Unable to scan history due to VSS Error: File or project not found"

So far we've found this error to present itself when a file has been "Destroyed" in VSS. We are guessing that the act of "Destroy" is recorded in the VSS history, but the actual file/project is missing and thus VSSConverter can't do the migrate and simply flags it as something it can't do. We guess that kind of makes sense, but once in TFS you do loose the fact that something at one time was "Destroyed." For hard core configuration management pundits this could be like arguing if a tree falls in the woods does it make a noise if no one is around to hear it? That is, was something ever created if there is no history of it?

Error/Warning 2:
"TF60096: Unable to migrate due to Team Foundation Error: The item already exists."

The most common cause of this error (we think) is when you have project name conflicts. For example, we once had a source tree called $/prod3 that was created, filled with source, deleted, then created again, and filled with source again. Don’t even get me started on why! This was resolved for the most part by taking smaller chucks lower in the hierarchy. See this posting one the background and some examples of how we got around it. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=973933&SiteID=1

Error/Warning 3:
"TF60096: Unable to migrate due to Team Foundation Error: The item could not be found in your workspace."
"TF60096: Unable to migrate due to Team Foundation Error: TF14022: The deleted item does not exist."
"Unable to migrate. "

We've seen these errors when no file history was migrated at all. We get a message in the comments saying "Tip Version match Checkin---- DO NOT MODIFY. VSSConverter comment. Verification complete ----" which think is due some combination of deleting a file, recovering a file, and then renaming it (as a side note it's also a pretty lame error message). For example this is what we saw in the VSS history. I've purposely XXXXXXX'ed out the intern ;) who exercised themselves with this renaming experiment.

***************** Version 63 *****************
User: XXXXXXXX Date: 10/14/05 Time: 10:23a
Renamed application_STABLE.xml to application.xml
***************** Version 62 *****************
User: XXXXXXXX Date: 10/07/05 Time: 12:04a
Renamed application.xml to application_STABLE.xml
***************** Version 61 *****************
User: XXXXXXXX Date: 10/07/05 Time: 12:04a
Renamed application_STABLE.xml to application.xml
***************** Version 60 *****************
User: XXXXXXXX Date: 10/07/05 Time: 12:04a
Renamed application.xml to application_STABLE.xml
***************** Version 59 *****************
User: XXXXXXXX Date: 10/06/05 Time: 2:20p
Renamed application_STABLE.xml to application.xml
***************** Version 58 *****************
User: XXXXXXXX Date: 10/06/05 Time: 1:39p
Recovered application.xml
***************** Version 54 *****************
User: XXXXXXXX Date: 10/06/05 Time: 11:02a
Deleted application.xml

In conclusion, we hope you find this information valuable. Feel free to comment if you have additional information or disagree with our conclusions.