TFS 2010 version control upgrade bug in handling labels, merges
UPDATE [6/12/2010] The patch is now available on MSDN Code Gallery here. You must install it after you complete the MSI setup portion (the files need to be on the machine and registered in Windows first) and before the upgrade wizard (it’s the upgrade process, not setup that needs to be patched).
- Run the TFS 2010 installation and quit/cancel once you get to the upgrade wizard (do not upgrade).
- Install the patch.
- Go to Start –> All Programs –> Microsoft Team Foundation Server 2010 –> Team Foundation Administration Console and then launch the upgrade wizard again.
- Go through the upgrade process as usual.
We discovered a couple of bugs in version control when upgrading to TFS 2010. They affect labels and future merges, and whether or not you are affected depends on what renames you have done on files in labels and branches. We are currently testing a fix that we expect to release shortly. The fix, when released, must be installed before upgrading to TFS 2010.
- Labels that were created before the upgrade are entirely empty. Labels could be also have incorrect contents.
- The merge wizard in Visual Studio does not display all valid merge targets for a given source path/branch.
- During merging, merge candidates are shown for changes that were already merged prior to the upgrade.
If you’ve already upgraded to 2010 from a previous release, you’ll need to decide whether there are labels that are critical for you. If there are, fixing the label problem after an upgrade without the fix will likely require access to the original version control database prior to the upgrade. You’ll need to contact customer support to get help with fixing the affected labels (customer support will not charge for incidents related to this upgrade bug).
The merge issue is simpler to recover from, and it’s largely an annoyance. You can read the KB article to understand what must happen. The fix for the issue of merge targets not showing up in the merge wizard is to do a non-recursive baseless merge of the source to the target via the command line (e.g., tf merge /baseless dirA dirB). Then the target will show. The children will end up being baselessly merged, which will be annoying and tedious, but you will be able to recover and move forward.
The underlying cause of both problems is the handling of renames during the upgrade, as described by the KB article. In TFS 2010, we changed the schema of version control to change something called an item ID to effectively become a path ID. In both 2005 and 2008, every item added or branched in version control got a unique item ID forever. So no matter what name or path changed to, the item ID never changed. This allowed for completely tracking renames forever, no matter how complex. However, it came at the price of introducing the confusing concept of a deletion ID, since a path could have more than one item at a time if there were at least one deleted item, and the concept of a namespace conflict, which occurs when two different non-deleted items (each has a different item ID in 2005/2008) tried to occupy the same path at the same time. If you’ve ever had to resolve namespace conflicts in 2005 or 2008, particularly as a result of a merge, you know the pain I’m talking about. It also resulted in significant complication of the SQL, resulting in lower performance and scalability than otherwise would have been possible.
So, we changed the schema such that a path uniquely identifies an item, turning the item ID into a path ID. Matt talks about some of the implications of that in his post, Changing to Slot Mode in TFS 2010 Version Control. Having used the server with the schema change for more than a year now internally, the change produced a faster, more scalable version control server, and the elimination of things like namespace conflicts has made merging less painful.