Killing off TFS 2005: Part 4

Posted 27 April 2011, 12:12 | by | Perma-link

Yay for short working weeks! I started writing this post last week, and then Easter came along and this week's even shorter as we've been given an extra bank holiday so we can all go and watch the Royal Wedding, which will be fun for all concerned I'm sure - hope the weather holds, but it's not looking great at the moment…

Last time we tried Killing off TFS 2005

We'd started the dry run of our TFS Integration process on the test server TFS10. This had started migrating some of the work items, but also had issues with a missing Work Item Type. I then left it running, and went on holiday…

The full series

State of the nation

I got back to discover that the server had been restarted at some point during the last week (thanks for the mandatory Windows Updates on the servers chaps Wink) but after some digging discovered that the process had crashed with an "Out Of Memory" exception. I suppose trying to migrate part of an 11GB TFS instance to another database, on the same server was a bit much to ask. Luckly, TFS10 is a virtual machine, so a quick shut down/re-configure/restart we were back in operation with 6GB of RAM. and I tried again.

I imported the missing Work Item Template to the target project, and then all 2,930 Work Items imported without any problems.

However, I had a number of issues with the version control migration, many of which in the end, I've not been able to resolve:

  1. The workspace names are a combination of the server name, the current instance GUID and your Session Names, and this must be less than 64 characters or errors will occur - The work arounds for this is are:
    1. Change the WorkSpaceRoot application setting in the MigrationToolServers.config file in the TFS Integration Tools install directory to be as short as possible
    2. Ensure that the "Name" fields of the Left and Right Version Control Session Sources are short but meaningful.
  2. Related to 1 - we've got some historical check-ins to folders that resulted in a total path length of over 260 characters, for various reasons TFS can't cope with this, and other than carrying out the steps in 1, there's nothing you can do about it.
  3. Regardless of what the tool states, you can edit the Version Control filter pairs after the configuration has been saved to the database if you're happy to edit the XML directly, just remember to leave off the trailing "/" - however this will result in the Discovery and Analysis phases running again.
  4. We've already performed some sort of merge from different projects into one of the projects we're trying to merge, and this caused an issue because the TFS Integration Tool couldn't find a workspace mapping for these old, no longer existing projects - I was hopeful that this could be resolved by adding a new filter pair to try and map them in manually, however I've not been able to confirm this completely.
  5. Various Null Reference Exceptions stating that the Path could not be null that caused the migration to stop.

So, in the end, I've had to pull the plug on this experiment, and live with a seperate Team Project Collection for the legacy code base - I'll keep telling myself that "It's probably ok, we're not going to be working on them side-by-side" and things like that, but in the end I'm a little sad that it didn't work.

If you've got a fairly simple, or small history (or you're happy to drop a good portion of it), you know that file paths are short enough then I think the Team Foundation Server Integration Platform is a great tool, but as they warn you throughout their documentation, it really should only be used if you absolutely have to, and you can't live with an upgrade (a note on that - For some reason, on the live TFS2010 box, I actually had to restart TfsJobAgent to get the upgrade to complete, as the new Project Collection wasn't created until I restarted it).

Filed under: TFS

Archive:

Tags: