One major part of the VSTS project, is the migration of existing assets from VSS into TFS.

MSDN article: http://msdn2.microsoft.com/en-us/library/ms253060(VS.80).aspx

I wrote this post  over several weeks so as to group migration related stuff together, so don’t mind the changes in tense.

The initial plan is to only migrate the source code and assets of the App Dev group. We did some test runs during the planning phase and the idea is do this during the Test (QA) phase of a patch, viz. to lockdown VSS and ask developers to hold-off check-ins.

For us, the migration mainly consists of asp, vb script and some .NET 1.1 and 2.0 code. FYI, the type of artifacts do not really matter because the migration is file-based.

One of the key decisions made was around what items to migrate. We decided to leave the C++ code in VSS since it is being deprecated and rarely modified, but migrate classic asp code to TFS so that developers could use only one dev environment…to fix bugs in classic asp and to develop new features in .NET 2.0.

Another key decision was planning our target Team Projects and the related Configuration Management process, which I will write about in another post.

Before I bore some of you with details of the migration, let me jot down some lessons learnt:

  • Be aware of the differences between TFS and VSS (linking, labels, etc.)
  • Know the limitations of the conversion tool (labels not converted, etc.)
  • Plan your target Team Projects well. 
  • If you have a big folder to migrate, split the conversion into smaller chunks of it’s sub-folders. Have a small plan for the root files.
  • Work on a copy of the VSS database, so you can manipulate folders in there.
  • Do not do test migrations in the “production” TFS because there is no way to clean up clutter. Hopefully the “destroy” feature in Orcas will resolve that.
  • Plan to keep VSS around for a while as an archive and a reference (for labels, etc.)

Now, the details: 

We are using the VssConverter (command-line) tool for the migration. There is a GUI written for this (http://www.epocalipse.com/blog/2006/04/06/vssconverter-gui/) but  we didn’t really care about it. It’s a pretty simple tool that basically migrates a folder from VSS to TFS based on a bunch of settings defined in an XML file. It needs SQL Server (Express is fine) to store intermediate information as part of the process. Note that it also needs VS 2005 installed on the machine.

There are some caveats to this migration process, that you will need to consider depending on the layout of your codebase, because some features of VSS like shared or linked files are not supported in TFS. Our solution to that was to eventually duplicate these items and use them independently for now. The linked stuff makes it confusing anyway and the “right” solution for this (VSS or not) is to include files across projects.

One limitation of the tool is that History comments of files are migrated, but the timestamps are not; they are instead prefixed in the comments. The check-in timestamps in TFS reflect when those versions are checked-in into TFS (I assume the tool just uses the TFS API instead of hacking the original timestamps into the database).

This may not be critical but may be important if you’re doing some time-based analysis or sorting. 

 Also, an important to-do is to first run the Analysis option and map the VSS users to TFS users (in an XML file). (I do not know what user it defaults to for unknown users in TFS).

To isolate the migrated assets, I created a Team Project called Production and put in the stuff into a folder called Legacy. I did this with the idea of eventually moving “used” files into another branch so dead files can be weeded out.

This blog post giving good insight into the conversion implementation: http://blogs.msdn.com/ankur/archive/2005/09/14/466493.aspx

Network problems disrupted our migration and although the tool could resume a few times, the last disruption messed it up and it kept giving an error (I forgot what exactly) and I had to do some major hacking to complete the migration.

I ended up on the MSDN boards and finally got in touch with Ankur, who I think was the main author of the tool. He was a great help in pointing out things which were not possible in the tool and in TFS, so I had to do some very weird workarounds to convert the remaining files.

My major problem was that a large sub-folder was taking too long to convert and we had a network glitch each morning that threw it off and so I had to split it into smaller chunks for conversion. Although one can specify sub-folders to migrate, files in the root pose an issue since the conversion tool is folder based and not file based. So, I ended up making a copy of the folder in VSS and dropping all the sub-folders so it only had the root files and then specifying the same target in TFS. Note: I did try creating a new folder (project) in VSS and dropping (which created links) the root files in it. But then the tool would not pick up any history because they were linked files.

Anyway, our migration is now complete. I did a compare from the files in VSS and TFS and things look good. If you need help or advice about this, feel free to contact me.