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).

  1. Run the TFS 2010 installation and quit/cancel once you get to the upgrade wizard (do not upgrade).
  2. Install the patch.
  3. Go to Start –> All Programs –> Microsoft Team Foundation Server 2010 –> Team Foundation Administration Console and then launch the upgrade wizard again.
  4. 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.

The issues are described in a KB article, which Matt published today.  Here are the symptoms that manifest after an upgrade without the fix.

  • 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.

Comments (8)

  1. buckh says:

    Stefan, thanks for pointing that out.  We'll get that corrected.


  2. Keith Hill says:

    Personally, we dealt with the namespace conflicts reasonably well in TFS 2008.  However Matt's post doesn't go into the "renaming" limitations in TFS 2010 which are likely going to cause us to put off migrating to 2010.  From experimentation it seems that if you have a one-way merge relationship (MaintenanceBranch -> Trunk) you are limited in terms of only being able to perform a single rename on an item in the target branch (Trunk).  After that, any further renames will lose the merge relationship between the MaintenanceBranch and Trunk for that item.  Unfortunately our MaintenanceBranches are around for a long time and require consistent servicing.  This means we are limited in the amount of refactoring we can do on Trunk for fear of loosing merge relationships between these branches.  Note: we would never merge Trunk back to a MaintenanceBranch, making these merges always one-way.  In the end, from my point of view, you fixed a somewhat corner case issue (add, rename, add) at the expense of a much more common scenario e.g. supporting multiple renames on the target branch (Trunk in our case).  I mean, come on, refactoring code on your mainline development stream is quite common, isn't it?  We can't be expected to keep track of rename counts (devs come and go – who's going to remember).  In the end, everybody would just become terrified of renaming anything involved with a branch and that's not a place you want to be with your SCM tools.  Fortunately 2008 has been working pretty well for us – supporting our particular scenario.

  3. buckh says:

    Keith, we're working with your company on it via customer support.


  4. Keith Hill says:

    And we very much appreciate the *awesome* support we've received so far!  The think that's nagging me though is that this change (which appears to be a significant change) didn't get more attention.  I mean, I read Matt's blog post some months ago but the apparent consequences didn't dawn on me until after the migration.  I can appreciate the position your team must be in WRT beta testing TFS. I mean who really wants to seriously test a beta of TFS on their production server?  Our IT department, which runs our TF servers now, wouldn't let us even if we wanted to.  And any test server that gets set up only gets a modicum of use/testing.

    My other worry is that somehow we're just not getting it and doing branching wrong somehow.  Honestly I'm just trying to understand, given the change, if we need to adapt how we do branching.  Anyway, I'm sure MS support will get us straightened out one way or another.  :-)

  5. buckh says:

    Keith, sorry about surprising you.  That certainly wasn't our intent.  It's really your extensive use of renames combined with merging, particularly since you are only ever merging in one direction in this case.  We made certain tradeoffs with the change in 2010 that aren't good in this case.  We are working on a solution that we believe will address this.  Stay tuned.


  6. buckh says:

    Ignaci, you'll find a table of recommended hardware for a given number of users in the TFS 2010 installation guide.  It's in the Team Foundation -> Team Foundation Server -> System Requirements section.…/details.aspx

    For example, here are the first two rows from the table.  Now, comparing this to the tests that Plastic SCM did is kind of tricky.  The reason is that they say they are using 100 clients.  Now, you have to determine for a real installation, how many people on your team do you think are hitting the server at any given time?  When we do these simulations, we're not assuming all 250 users in a 250 user system are simultaneously hitting the version control portion of TFS.  However, if you look at our recommendation for a 500 person team, it's reasonable to expect 20% of the team accessing version control simultaneously in the middle of the work day.  Either way, I think TFS compares favorably with the results they show given the same hardware used in their tests (it's newer than what we used in our tests).  There's no way I can say we're faster or slower.

    Fewer than 250 users

      Single-server (Team Foundation Server and the Database Engine on the same server).

      1 single core processor at 2.13 GHz

      2 GB

      1 disk at 7.2k rpm (125 GB)

    250 to 500 users


      1 dual core processor at 2.13 GHz

      4 GB

      1 disk at 10k rpm (300 GB)

    The other thing to consider is whether their data set is similar to what you work with.  They tested with a fairly small data size (1376 files, 22.4 MB).

    In the end, the only way to know how they really compare is to set up a couple of evaluation servers, check in your files, and run some operations across multiple clients.


Skip to main content