Comparing Team Foundation Source Control and Visual SourceSafe (VSS) 2005

One of the key reasons for examining both products is to determine which one is the most appropriate for your environment. In most cases, your best bet is to move over to Team Foundation version control because you can also pick up the integration with the rest of Team System. In other words, you can now run automated tests on your code, build the source using Team Foundation Build, create work items to monitor bugs, receive automated alerts, apply check-in policies, apply a very granular level of security and generate detailed reports on everything from code churn, bug rates, and build results. Team Foundation version control is part of a greater Software Configuration Management (SCM) solution. Unlike Visual SourceSafe, Team Foundation version control is designed to scale to large development teams and can support distributed and outsourced teams in remote locations. Plus you will avoid problems such as the occasional corruption of your source code files (since the data is written to a database rather than flat files).

Microsoft Visual SourceSafe 2005 retains a role for smaller development teams. It has a few enhancements such as HTTP support, a better lock-contention mechanism, better performance over a network, and internalization support. Visual SourceSafe 2005 is available for a fee and is bundled in select versions of Visual Studio 2005.

As a rule of thumb, if you need Team System to manage your development projects, you should seriously consider migrating your code to Team Foundation version control. Let's quickly compare the features of both products in Table 20-1.

Table 20-1

Team Foundation Version Control	Control Visual SourceSafe (VSS) 2005
Supports up to 2000+ concurrent users	Supports a small number of users
Has no support for Sharing and Pinning. It will replace a pin with a label during the migration process.	Supports Sharing and Pinning
Supports Atomic and Transactional check-ins. Nothing is committed to the repository until the transfer has been completed successfully.	No rollback capabilities. File integrity can be compromised if there are connectivity issues.
Server-based source repository. Your source code is stored in SQLServer 2005 and accessed by Team Foundation Server via XMLWeb Services.	Encrypted file-based source repository, usually stored on a network
Project and feature security is tied directly to Windows user accounts and security can be set on a more granular level for different features of Team Foundation Server.	Rights are separate from Windows permissions. All SourceSafe users have access to the shared folder and source code.
Considerably faster than Visual SourceSafe	Speed limited by file access constraints and network latency
Access rights controlled using Windows user accounts and NTLM authentication. Team Foundation version control also supports Basic Authentication, which is useful when providing HTTPS access over the Internet.	Access rights set within VSS and Windows file sharing
Creates changesets, which bundle your source code, comments, and other data for easy future access	Does not support changesets
Supports Team System–specific features such as work items, Team Build, etc.	Does not support work items and does not integrate directly with the Team Build system
Supports check-in policies, auditing, and locking	Does not support check-in policies, auditing, or locking

Microsoft has developed a migration tool called VSSConverter to enable you to migrate your Visual SourceSafe code to Team System. The migration can be broken into two phases: In the first phase, you analyze the VSS database, and in second phase, you do the actual migration from the VSS database to Team Foundation version control.

The first phase, or the analysis phase, is going to generate some reports for you, indicating the potential data loss that may occur during the migration. Using these reports, you should be able to configure some of the migration options to minimize this loss. Be aware, however, that some data loss is unavoidable. This is due to some aspects of the VSS data not being mapped into Team Foundation.

Once you are satisfied with the results from the first phase, you can proceed with the actual migration. Once the migration is complete, you will again receive a report, detailing any errors or warnings encountered during the migration.

While a detailed walkthrough of the conversion process is outside the scope of this book, we will present a high-level overview, as well as refer you to where you can obtain more detailed information. The following paragraphs describe the general process for migrating from VSS to Team Foundation version control.

First, you need to install VSS on the machine on which you will be doing the conversion. Remember, the VSS database that you will be migrating to must be version 6.0. If it is an older version, please use the DDUPD utility (at http://www.msdn.microsoft.com/library/en-us/guides/html/vstskupgradingvisualsourcesafe.asp) to upgrade the database. Make sure that you install VSS 2005 on the conversion machine as well. To decrease the migration time, it is recommended that you copy the VSS database to a local directory on the conversion machine. Also, running the Analyze.exe application (at http://www.msdn.microsoft.com/library/en-us/guides/html/vsgrfss_analyze.asp) can help you find and fix any integrity and corruption issues before you begin the analysis and migration of the database.

The VSSConverter application uses SQL Express in the migration process. SQL Express needs to be installed on the conversion machine, before the analysis and migration are started. Make sure that you have administrator rights on SQL Express before you continue. Also, make sure that you install Team Explorer on the conversion machine. The VSS converter application is part of the client portion of Team Explorer. Before you start the migration, make sure that you are a member of the Team Foundation Administrator group on the Team Foundation Server.

At this point, you are ready to run your analysis. Remember, the migration process is going to be time consuming, depending on the amount of data involved. One recommendation is to migrate sources one project at a time, which will typically be one folder. Once you know which folders to migrate, you will create the settings file. This is an XML file containing all the options for the migration. Once this file is ready, you run the VSS Converter application to begin your analysis. For more detailed information on the analysis phase, please refer to the MSDN Library: Preparing To Migrate From Visual SourceSafe to Team Foundation (http://www.msdn2.microsoft.com/en-us/library/ms181246).

After the analysis is finished, a report file is generated. This file indicates some of the conversion issues that will occur during the migration. Here is a brief list:

• Sharing isn't supported in Team Foundation version control. As a result, a copy of the file(s) will be made to the destination folder from the point in time the file(s) were shared.

• As branches in VSS require sharing, the file(s) will be copied, and any changes in a branch will also be copied over to the corresponding branch in Team Foundation version control.

• Pinning isn't supported in Team Foundation version control. In the migration process, the converter will add "PINNED" in the label of your pinned files.

• The check-in dates in Team Foundation version control won't match the check-in dates for Visual SourceSafe. The original SourceSafe timestamp is typically appended in the comments.

The analysis phase will also generate a user map file. This file shows all the users who have performed any sort of operation on the folders that were analyzed. This file is also used to map Visual Studio users to Team Foundation users. (Take note that this step is optional.)

Before you can move over the source code, you must create a Team Project that matches the name of your VSS repository. The VSS files will subsequently be moved over to the corresponding branch on Team Foundation version control.

Finally, you are ready to perform the actual migration. Before you begin, make sure that you have identified the destination folders in Team Foundation version control for each folder in VSS. If the destination folder already exists, it must be empty. If the destination folder does not exist, the VSS Converter application will create it automatically. Next, you need to make modifications to the settings file (for example, map the VSS users with the Team Foundation server users) to prepare it for migration. At this point, you are ready to run the VSS Converter application, and migrate the database. For more detailed information on the migration phase, please refer to the MSDN Library: Migrating From Visual SourceSafe to Team Foundation (http://www.msdn2.microsoft.com/en-us/library/ms181247).

Once the VSS Converter application is finished, you need to review the report file to see what errors and warnings occurred during the migration. You will also need to change the source control bindings of the solution files from VSS to Team Foundation. (See http://www.blogs.msdn.com/akashmaheshwari/ for more information.)

If you work in both Visual SourceSafe and Team Foundation Source Control, you can select what version control system you want to use. Visual Studio 2005 has a plug-in selection option that can be accessed by clicking Tools Options and then Source Control Plug-In Selection. The default plug-in is Visual Studio Team Foundation Server. (Team System supports an extensible plug-in architecture.) You also have the option of connecting to another source control application such as Microsoft SourceSafe 2005. Figure 20-1 illustrates the Source Control Plug-in Selection Window.

Figure 20-1

Source code migration

Visual Studio 2005 and Team Foundation Build are primarily designed to support software written using the .NET Framework 2.0. Team Foundation version control supports any programming language, format, and file type. (In essence, if you can save it to disk it can be stored in the repository.) An interesting challenge comes up if you are storing source code using the .NET Framework 1.0, 1.1, Visual Studio 6.0 (or even on other platforms). Team Foundation version control is naturally designed to integrate with Team Foundation Build. Since Team Foundation Build builds .NET 2.0 code by default, you may need to customize your build scripts and use alternative tools to manage your source code. Table 20-2 is a matrix covering the common scenarios you may encounter.

Table 20-2

Scenario	Action
You have VB 6.0 or VC++ 6.0 you would like to import into Team Foundation version control	You can choose to run Visual Studio 6.0 side-by-side with Visual Studio 2005. You can then import Visual Studio 6.0 projects into Team Foundation version control using the command-line tool or the MicroSoft Source Code Control Interface (MSSCCI) client. For more information, visit http://www.msdn.blogs.com/bharry/archive/2006/02/21/535985.aspx.
	You can quite easily add any files by Visual Studio 6.0 to the repository by creating a workspace and using the Add File. The problem occurs when you try to check out the files—Visual Studio 2005 will "assume" that you want to upgrade and then will launch the Upgrade Wizard.
	Another option is converting your code from VB or VC++ 6.0 to the .NET Framework 2.0. For example, if you attempt to open a VB 6.0 project in Visual Studio 2005, the Upgrade Wizard will appear. There is also a lot of migration documentation on the MSDN website: http://www.msdn2.microsoft.com/en-us/library/.
You would like to import and build .NET 1.0 or 1.1 code in Team System	In most cases, attempting to open and save a .NET 1.0 or 1.1 solution in Visual Studio 2005 will result in a solution that will no longer open in Visual Studio 2002 or 2003. The reason is that Visual Studio 2005 only supports the .NET Framework 2.0.
	So what are your options? You can install Visual Studio 2002/2003 and Visual Studio 2005 side-by-side. By opening your older solutions in the older versions of Visual Studio, you will avoid any migration issues.
	To download the MSSCCI plug-in to connect Visual Studio 2002/2003 with Team Foundation version control, please refer to the following link: http://www.go.microsoft.com/fwlink/?LinkId=58454.
	Another option is upgrading your application to the .NET Framework 2.0. This is facilitated by the built-in Upgrade Wizard. The downside is that you will have to deal with migration issues; however, the upside is that you will be able to import and export your source code using Team Explorer.
	There are two tools available to build .NET 1.1 within Team Foundation Build. The first tool is called MSBuild Toolkit and is available on the following website: http://www.downloads.interscapeusa.com/MSBuildToolkit_v2_RC.msi.
	The second tool is called MSBee - MSBuild Everett Environment. It is being developed by Microsoft—more information is available on the following site: http://www.blogs.msdn.com/clichten/.
You would like to migrate ASP.NET 1.0 or 1.1 code	The Upgrade Wizard will help you migrate your application to ASP.NET 2.0. By experience, the easiest way to migrate 1.0 Web services is to recreate them in 2.0 and copy and paste your source code.
	Keep in mind that launching ASP.NET 2.0 websites will automatically launch the local Cassini Web Developer server by default. You should configure the virtual directory in your IIS server to host your application and set Visual Studio to launch without Cassini if you are developing web applications alongside Web services. ASP3.0 applications are compatible but will not compile under Team Foundation Build.
You would like to import source code from another platform (such as Java code) into Team Foundation version control	There may be circumstances where you will be need to deploy Team System in a mixed development environment. For example, half the company may be using PowerBuilder, the other half .NET.
	Team Foundation version control is quite versatile and can store different file types including projects on other platforms (such as Java projects). Obviously, code from other platforms will not integrate as nicely with the testing tools and the build engine. However, it is possible to launch remote builds using the Windows Task Scheduler, programmatically hooking it into the Team Foundation Eventing Service—you have a lot of possibilities at your disposal.
	Teamprise (at http://www.teamprise.com) has developed a plug-in to enable Windows, Mac, and Linux to integrate with Team Foundation version control and Team Foundation's work item tracking system. Teamplain (at http://www.devbiz.com/teamplain/) also a web-based application that enables you to manipulate the work item database. (In fact, it provides access to any part of Team Foundation Server accessible to Team Explorer including the build system and work items.) This web application will work on any platform, including the Mac OS and Unix-based systems.