We have discovered a potentially serious issue that can affect upgrades from TFS 2005 or TFS 2008 to TFS 2010.  The issue is triggered by a specific pattern of labels, renames, deletes and/or branches that existed before the upgrade.  Once the upgrade is complete the contents of the affected labels could be incorrect.  Also some internal merge tracking data could be incorrect, resulting in the need to reapply previous merges.  Under no circumstance will it cause the contents of any source code to be modified or lost.  You can read more about the issue in this KB article:

http://support.microsoft.com/kb/2135068

Any time TFS fails to properly preserve historical information, we take the issue VERY seriously and react quickly.  So far we’re heard of about 5 customers who’ve been affected by this.  We expect, based on the repro conditions, that relatively few people will but we’re working hard to ensure anyone who is can get help and to enable future upgrades to avoid the issue altogether.

If you haven’t upgraded to 2010 yet, you’re going want to know how to avoid the problem.  The good news is that we have a fix that will prevent the issue.  You can download the hot fix from the download tab of this Code Gallery page: http://code.msdn.microsoft.com/KB2135068.  You will not need to change your planned upgrade process in any significant way.  You will just need to insert a step.  When you get to the end of the initial install page, you will get to a window that looks like below.  You will want to uncheck the “Launch Team Foundation Server Configuration Tool” checkbox at the bottom left and click Finish.  At this point you will run the hot fix I gave the link to above.  TFS install is patched and you can continue with the upgrade process without fear of hitting the issue.  To continue the upgrade process you need to run the Team Foundation Administration Console from the Microsoft Team Foundation Server group on the Start menu.  It will then lead you through the rest of the upgrade process.

One minor note to head off a likely question… Despite the fact that the patch file is named “VS10-KB2135068-x86.exe”, it will work on both 32 and 64-bit TFS installs.

The online install guide has been updated with a note about installing this important hot fix.

We are also working on a new TFS installer that will include this hot fix so that down the road as people go to upgrade their servers, they won’t have to learn about or separately install this hot fix.  My hope is that the new installer is available within the next few weeks.

If you’ve already performed your upgrade, the first question you are going to want to know is whether or not you’ve been affected.  We’ve built some scripts to help you identify any occurrences of the problem.  Attached to this blog post are two sets of SQL scripts.  One set can be used on a TFS 2010 project collection database to determine whether or not any errors were introduced in the upgrade process.  Because some merge relationship information is potentially lost in the upgrade process, the scripts are “pessimistic” and may report a potential problem even if none exists.  If the tool reports a problem, you will need to call customer support to have them help you confirm the issue and determine a strategy to correct it.

The scripts to check a TFS 2010 upgraded database are in “Check for Issue.zip” attached to this blog post and include:

  1. MergeHistory2010 – returns the items which “may” have a missing relationship. It’s possible for the script to generate false positives, so the customer should review the relationships and possibly call CSS before performing the baseless merge.
  2. Labels2010 – produces a best-effort list of labels that have issues.  May generate false positives.

Because we have to make pessimistic assumptions about what might be problem, you should consider going back restoring a copy of your TFS 2005 or TFS 2008 version control database and running the second set of scripts on them.  Because they contain all pre-upgrade information, we can definitively whether or not the upgrade process will have introduced an error.

The scripts to check a TFS 2008 or TFS 2005 version control database are included in the “Check for Issue.zip” file attached to this post and it includes:

  1. MergeHistory2008 – returns an “Issue Exists” if the customer is going to hit the problem and “All Clear” if not.
  2. Labels2008 – returns an “Issue Exists” if the customer is going to hit the problem and “All Clear” if not.

UPDATE 6/28/10 - I've just added a new script to the attached zip file called "MergeHistory2008WithResults" that can be run against a TFS 2008 database (just like MergeHistory2008) but rather then just producing a boolean Issue Exists or All Clear, it returns a list of all of the merge sources and targets that are going to have problems when converted to 2010 without the hot fix.

You can run these scripts any way you normally run a SQL script.  For instance, you can paste them in to SQL Server Management Studio after connecting to the proper database or you can use OSQL to run them from the command line.

Unfortunately, if you are affected, correcting it is not easy.  You will need to call Customer Support and they will help you work through the issues.  Customer support will not be charging for any incidents drectly stemming from this issue.

I’m very sorry for the difficulty that this has caused some of you.  We are looking hard to understand how this escaped our QA process and what we can learn from it to avoid it in the future.  The issue has actually been in the product since before Beta 1 and was not identified through the entire Beta testing process.  I believe that, in part, this reflects the relative rarity with which people will hit this issue.

Please let me know if there is anything I can do to help,

Brian