Visual SourceSafe

Most software development groups understand and probably have experienced at least once during a product's life cycle the value of using a source-code control software package,such as Microsoft's Visual SourceSafe (VSS). And now that VSS has been integrated with Microsoft Visual Studio 2005 and SQL Server Management Studio it's easy to administer, making it the source-code management software of choice for a Microsoft environment.VSS tracks changes made to the code over time, recording not only the change but also who made it, when it was applied, and why it was made, all in an easy-to-read format. Let's take a look at how to install the client application, set VSS options for your environment, add a user to the environment, and check files in and out of VSS.

VSS Installation Overview

VSS comes in two versions—a standalone version for individual users whose database is stored on a local machine, and a Shared Database Server version for an enterprise that stores its database on a server for shared use. We'll focus on the shared VSS application. For more information about installing the standalone VSS version, see the Microsoft article "Installing Standalone VSS" at http://msdn.microsoft.com/library/default.asp?url =/library/en-us/guides/html/vstskinstallingstandalonevss.asp. For a quick overview about installing the Shared Database Server version, see the Microsoft article"Installing the Shared Database Server" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/guides/html/vstskInstallingshareddatabaseserver.asp.

Before you install VSS in your enterprise, the project team should meet to discuss the different roles team members will be assigned for the project and the processes that need to be established for using VSS. For more information, see the Web-exclusive sidebar "Defining VSS Roles and Processes" at http://www.windowsitpro.com, InstantDoc ID 49478.

Installing VSS is a two-step process:The VSS administrator needs to install the VSS administration application on a server, configure the Project environment, and add all the users who will be able to check files in and out of VSS. Then, users install the VSS client application on their workstation.

Only users who have been configured with the Admin role and password ( configured during the installation process) can access the VSS Administrator application.As part of the installation process, the VSS Administrator specifies a location on the server for the VSS folders.VSS uses this location to create a directory structure for the following VSS folders:

Setting VSS Options

After you've installed the Shared Database Server,the VSS administrator should log on to VSS.The first window the administrator sees is the Visual SourceSafe Administrator window, with four options on the VSS toolbar: User, Tools,Archive, and Help. Select Tools, Options to display the SourceSafe Options tabs.

The SourceSafe Options tabs (which Figure 1 shows) let administrators customize VSS to their company's needs. We'll explain how to use the General, Project Rights, Shadow Folders, and File Types tabs in this window to configure VSS options for the enterprise's development environment before each user installs the client interface on his or her workstation.(Note that the FileTypes tab isn't visible in Figure 1, and we don't discuss the Web tabs in this article.)

General tab. The VSS administrator uses this tab to set up the VSS environment. Select Allow multiple checkouts if you want developers to have the flexibility to work on the same piece of code simultaneously. Although this is a useful feature, be aware that when developers check multiple versions of the same code into VSS, modifications are merged into one file.

Select Use network name for automatic user log in if you want to bypass the VSS security and rely on network security to grant access to the VSS database.(See"Adding a User"later in this article for information about assigning a user ID and password that are independent of the server security schema.) Selecting this option makes access to the database less secure but makes the integration of VSS into your network environment seamless.

In the Default Database name: field, enter the name of the default VSS database. If the development team is working on a large code base or if different development groups are working with various databases, you should configure a different default database for each project or department. The VSS administrator must assign the default database name before the developers install the VSS client software on their workstations; otherwise, the client software won't be aware of the configured default database name.

Each file checked in and out of VSS has its own history log. Enter a filename (or use the Browse button) in the Log all actions in journal file: field if you want VSS to save the actions logged for all files in a separate journal file.This option provides a centralized repository for changes made to files to support administrative review.

Project Rights tab.This tab lists the options the VSS administrator uses to customize user rights for each project. To begin, select the Enable Rights and Assignments commands option if you want the selected New User Rights permissions (i.e., Read, Check Out/Check In, Add/Rename/Delete, Destroy) to be inherited by all new users for a project. If you want to assign user rights on a per-user basis, don't select the Enable Rights and Assignments commands option.

As the name implies, Destroy permission lets a user delete a file permanently from VSS, thereby removing it from the database and making it unrecoverable. Obviously, only a limited number of users should be granted Destroy permission.

Shadow Folders tab. Shadow folders reside on your file server and contain the latest checked-in versions of all of the files for a particular project.This option lets you specify a centralized area to view and compile source code that is in working condition, meaning the code is the most current version. You should select the appropriate shadow folders options when there are several developers working on a project simultaneously and the project's source code needs to be compiled for regular review.

To create a centralized area, enter a project name (e.g., $/Project102) in the Set shadow folder for project: field, and enter a Project folder name (e.g., C:PROJECT102) in the Set shadow folder to: field (as Figure 2 shows). Use the Files in Shadow Folder area on this tab to set characteristics (i.e., read-only flag, end-of-line character, and date/time stamp) for files saved in the specified shadow folder. Figure 3 shows the resulting Project102 tree structure.

File Types tab. Use the File Types tab to specify a location for a group name for a set of file extensions. For example, you could create a file group called SQL and include file extensions such as .sql. These group names will help VSS filter files in a directory when you are working with the VSS interface to check in files, check out files, and so on.You should remove any of the standard file groups that are set up by default if your group doesn't use them.

Although VSS provides security to the database through the VSS login option, I strongly recommended that you restrict permission to share folders to the folder containing the VSS database. The VSS database provides detailed instructions in online Help about how to lock down the database on your network. These instructions will guide you through the processes of removing any default groups that are given access to the folder and of giving the appropriate access to the VSS Administrators group and the VSS Users group.

Adding a User

The next step for the VSS administrator is to create users. On the initial Visual Source-Safe Administrator window, on the VSS toolbar, select User, Add User. Enter a user ID and a password for the project developer and repeat this process for each developer on the project. After the administrator enters an ID and password for each developer, the developers should install the VSS client application on their workstation.

If you are using the network name option for automatic logons, then the user ID must match the network name. The VSS administrator can assign each user rights to his or her respective projects.You can assign rights by project or user.

Installing the VSS Client Application

The VSS administrator needs to tell the developers where the NetSetup utility resides on the file server—the NetSetup utility installs the VSS client application. When you installed the VSS Administrator application, as part of the setup process,VSS stored the NetSetup executable file in the NetSetup folder. When a developer clicks the netsetup.exe icon, the NetSetup installation wizard opens and guides the developer through the VSS client installation. After the client software is installed on a developer's workstation, he or she can change his or her password by selecting Tools, Change Password.

Checking Files in and out of VSS

After you install the VSS Administrator application and client software, the snap-in to VSS becomes available in SQL Server Management Studio.To configure additional VSS options from SQL Server Management Studio, select Tools, Options, Source Control, Plug-in Setting, Advanced.

SQL Server Management Studio and Visual Studio .NET now have the same IDE, which means you can organize your T-SQL code in the same manner you do Visual Studio projects. Using SQL Server Management Studio provides an easy way to organize, manage, and save your code in both the SQL database and VSS.

Another item you'll want to determine is the structure for each project. For example, you might want to store all procedures, triggers, views, and ad hoc queries for a particular application in one project, or break these elements up into multiple projects under one Solution.The key is to create a structure that will be intuitive to all the developers who check files in for a particular project.

Before continuing, let's discuss the concept of working folders. The VSS database houses the latest copy of code, along with a history for each file. However, until a developer checks the code in to VSS, the code resides on the developer's hard disk or a personal network drive folder (called in VSS the working folder).After the developer adds a file to VSS, the file should be removed from the working folder until the developer needs to make modifications to the code. It's best to use VSS as the central repository for all files. To make modifications, a developer must check out the code from the working folder.

Let's walk through a simple example of how to create a Solution, execute it on the server, and check it in to VSS.

You can continue to place additional TSQL code under the Queries folder in your project.You can add each query to Source Control as it is completed by right-clicking on the project and selecting Add existing item.You need to check out the Solution file and project file from VSS before you can add more files;VSS prompts you to check out the project files when you add a new file.

Modifying a Stored Procedure

Follow these steps to check out a file for editing, check it back in to VSS, and execute a file comparison.

As you can see, after you set up a Solution in VSS, it's easy to retrieve the file to make changes.With the integration of VSS in SQL Server 2005, these tasks have become seamless.

Is Your Environment Under Control?

Version control isn't just about software: It's also about processes that are enabled by the right software.VSS provides SQL database developers in small-to-midsized software companies with a tool that can centrally manage all of the enterprise's code that's readily accessible from the SQL Server interface. Having the ability to centrally manage file-version control helps to simplify common tasks such as code reviews, project management, source-code change auditing, and backups. If used properly, version-control procedures and VSS should help your development team avoid costly mistakes such as overwriting source code, thus protecting the integrity of your data and improving the productivity of your development team.