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:

• Data folder—contains multiple sub-folders that act as the database for all code files.VSS uses a file system as a database rather than a typical database such as Microsoft Access.
• Users folder—contains the initialization (.ini) files for each user. Each .ini file stores the VSS interface settings configured for a user. For example, the .ini file stores the location of working folders for each user. (We discuss working folders later in this article.)
• Temp folder—stores temporary files.
• Win32 folder—stores the Windows utilities that the VSS administrator uses to maintain the database for VSS.
• Setup folder—stores files used by the Setup program to install additional components or uninstall VSS.
• NetSetup folder—contains the files used to install the client version of VSS.
• Template folder—stores the VSS template used to create initialization files for each user.VSS copies this template file to the Users folder.You can customize this template for each user.

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.

1. When you create a new query, SQL Server Management Studio automatically creates a blank Solution (with 0 projects).
2. Add a project to the Solution. In the Solution Explorer (which is a component of SQL Server Management Studio), right-click on the Solution name and select Add new project. Select SQL Server Scripts and rename the file.
3. Write your T-SQL code in the query window.
4. Save the Solution, project, and SQL files in your working folder.
5. Execute your T-SQL code on the SQL server. (This step isn't necessary if your code is an ad hoc query.)
6. To add a SQL file to a project, right-click on the project name in Solution Explorer, then select Add existing file. Select the SQL file from your working folder.
7. To add the Solution to Source Control, access the main VSS menu. On the VSS toolbar, select the File option, Source Control, then Add Solution to Source Control from the drop-down menu. After you add the file to Source Control, the Solution, Project, and Queries folders display a lock symbol next to each filename in Solution Explorer. The lock symbol indicates that the file is under source control and is read-only.

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.

1. Access the main VSS menu. On the VSS toolbar, select File, Source Control, Open from Source Control. VSS prompts you for your VSS user ID and password.
2. If you have files in your working folder, VSS prompts you to verify whether you want to overwrite the changes. Another option is to open the Solution file directly from your working folder and select the Get Latest Version menu item to retrieve the latest version of the files from the VSS database.
3. Right-click on the SQL code that you want to update and select Check-out for edit. VSS prompts you to check out the project and Solution files and enter an explanation for checking out the file for historical purposes.
4. After the file has been checked out, you'll see a green icon next to the filename in the VSS menu.This icon indicates that the file is no longer read-only.
5. After you finish making changes to the TSQL code, you can execute the code on the server and check the file in to VSS. To do so, right-click on the filename and select Check-in.VSS prompts you to check in the project and Solution files as well as the SQL file.You could keep the project and Solution files checked out if you anticipate having to make additional changes to other queries in the Solution.
6. To scan the history of the query that you checked in to see what was changed, right-click the filename and select History. Select the two versions of the file to compare, then select Diff.VSS to display a two-pane window that lists the differences found in the two versions of code. Code that has been deleted appears in blue, code that has been edited appears in red.

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.