Introduction to Microsoft Visual SourceSafe

Microsoft's primary purpose in delivering Visual SourceSafe as a part of its Visual Studio .NET suite of development tools is to provide a project-oriented means of storing and organizing code that allows developers to spend more time developing their projects and less time managing them. The emphasis is on ease of use and integration with a wide range of development tools. SQL Server developers can benefit greatly from this ease of use and integration, not only with regard to source code, but also as a means of organizing related files such as project documentation and test data.

As with SQL Server, there are different ways to use Visual SourceSafe. It is essentially a client/server application, but if you are an independent developer, your development workstation will likely also be your application server, database server, and source code server. Of course, if you are an independent developer, you may be wondering why you have a need for source code control at all. I will discuss this issue later in the chapter. For now, you can take my word that source code control is just as important for the solo developer working on a simple project as it is for a large development team working on a complex, component-based project.

If you are a member of a development team, the Visual SourceSafe client will allow you to work with local copies of code while preventing other members of your team from overwriting your changes while you have the code checked out from the Visual SourceSafe database. The benefit of this simple concept is obvious, but you have to work with and become comfortable with Visual SourceSafe before its many other benefits will become just as obvious. After you have posted your source code, you can

• Get the current version of all files.

• Check out a copy of a file that needs to be changed. Visual SourceSafe is, by default, configured to prevent all other developers from changing the file until it is returned (checked in) to the Visual SourceSafe database. View differences between a local version of a source code file and the latest version stored in the Visual SourceSafe database.

• Label versions of files to identify them with a particular release of a software product.

• Retrieve older versions of a particular file or a complete set of project files.

• View changes between any two versions of a source code file.

• Share common files between separate projects.

• Make a single backup copy of the complete source code and all supporting files.

• Create branches of source code files to separately manage multiple versions of a software project.

• Merge code in different branches of the source code file.