After spending a day and a half on migrating Visual Source Safe (VSS) to Microsoft Team Foundation Server (TFS) source control, I want to share a few points that may save somebody a little bit of time.
Migration process consists of two phases: a) migrating data from VSS to TFS, and b) switching Visual Studio projects' source control bindings from VSS to TFS.
Data migration is done more or less the way Microsoft describes it: analyze, map users, and finally, migrate data. This part of the process didn't go as smooth as it could because my VSS data lived on a machine that is not a member of the domain, while TFS database lives on a domain computer. Unfortunately I wasted a lot of time before I found that out: after all, "analyze" step worked leading me to believe that migration itself will be possible, but in the end security problems didn't allow data migration. So here's the time saver hint #1: copy your VSS data (a folder with the srcsafe.ini file) to the domain computer where migration process will take place. Also, please keep in mind that the machine where you will run migration utility should:
- Have SQL Server or SQL Server Express installed;
- Have Visual Source Safe 2005 installed;
- Have Visual Studio 2008 installed. This one is important. MS says it's enough to have only Team Explorer for the migration process, but that's not quite correct: Team Explorer package of the VS does not contain "Visual Studio 2008 Command Prompt" BAT file necessary for the process. It's possible to work around it and create your own BAT file that sets all the paths properly, but it will take time. Running migration on the machine with the real Visual Studio is a time saver tip #2.
Once these requirements are observed, data migration problems are limited to the tedium of mapping VSS folders to TFS folders - if you want to consolidate and re-organize projects while moving them to TFS. If your VSS structure was OK as is, then you can simply move VSS to TFS structure without changing it.
Switching Visual Studio projects' source control bindings is no less a time sucker than data migration. This part should be done at one of the developers' machines, with Visual Studio 2008 with Team Explorer installed and projects that are being switched over from VSS to TFS already present as local files.
Here's a high-level sequence of steps required for changing source control bindings:
- Open a solution bound to the VSS in the Visual Studio.
- Select the solution in the Solution Explorer, and then do File | Source Control | Change Source Control, then select all items in the list and hit Unbind button.
- Select Tools | Options | Source Control and then select Team Foundation Server from the list. Hit OK to close the dialog.
- Use Team Explorer to open TFS source control window, and there use Workspaces drop-down list to select "Workspaces..." item and update mappings of your local file folders to TFS folders for this machine's workspace.
- Once done adjusting TFS to local folders mappings, select solution in the Solution Explorer and do File | Source Control | Change Source Control again. Now select all items in the dialog and hit Bind button. If all projects got "Valid" status next to them, it means your TFS-to-local-folders mappings are done correctly. If some project bindings are Invalid, find where these project folders are located on your file system and map them to corresponding TFS folders (see previous step) in your workspace. After that try to re-bind your projects to TFS source control again. Once you got all your projects in the Valid state, click OK to close the window, and at this point you are likely to get a nagging message from VS telling that you need to get latest version from TFS. Accept defaults.
- Get latest version for the solution. Project files are likely to need manual conflict resolution. I don't know why it's considered to be a conflict when it's just a change to the project files reflecting new source control bindings. Choose default type of resolution - Overwrite.
- After this Visual Studio may revert some projects to unbound state - leaving them off them source control. All you need to do is to, again, bind your projects. This time binding process offers to do regular Check Out for project files in question. Accept defaults and in the end you should end up with the solution that has a solution file and maybe some project files checked out, but otherwise the solution should be bound to the TFS now.
- Test-build the solution, and if everything is alright, check in modified solution and project files.
If this list seems convoluted - that's because the process of re-binding from VSS to TFS itself is incredibly awkward. Imagine making up this list of steps by trial and error. Hopefully using this list, as much pain as it is, will save you some time.