VSS Tips & Tricks

For most Microsoft development teams, Visual Source Safe (VSS) is chosen as the Source Code Management tool before alternatives (like Vault or CVS) are even compared. What this means is that if you work on one of these teams and you’re managing concurrent development, you’ll likely be doing so with the help of VSS. It’s also fair to say that most developers or de-facto VSS administrators don’t ever get a minute worth of training on how to use the features provided by VSS let alone how VSS works behind the scenes. In this article I will show you how to use VSS to automate certain processes and discuss how to use features you might not know exist.

Love it or hate it but, as Microsoft developers you’ve all probably used Visual Source Safe at some point. Most simply use it as a check-in and check-out code library to manage concurrent development. With so many developers using VSS, you might think you would see it improved and modernized as it is integrated with newer releases of Visual Studio but alas, this is not the case. By simply looking at the technologies VSS implements, we can easily see it is behind the times. INI files instead of XML Configuration files, poor performance over remote connections, and less than stable integration with the VB6 IDE, just to name a few. Even some teams at Microsoft use a homegrown command line tool called “Source Depot” instead of VSS. Having said that, there are plenty of things that VSS does do well, such as:

• Branching
• Labeling
• Check In and Check Out
• Cloaking
• Sharing

In addition to these standard features, there are tweaks you can perform to increase performance, automate keyword expansion, validate html links, and even have VSS generate a site map for your web projects.

The Invisible Login

Using the VSS Admin tool, you can turn on the option for your developers to “Use network name for automatic user login” but, if you decide that you want VSS logins separate from network logins, you’re going to be required to login each time you run the VSS Explorer. If you’re the type of person that likes to keep entering login credentials to a minimum, this feature is for you. By using environment variables, you can specify your VSS login (and optionally, your password) without having to type it each time you run the VSS Explorer. To do this, you simply create an environment variable named SSUSER and store your VSS login name in the value. If you choose to, you can do the same thing, using SSPWD to store your password. If you’re concerned about the security of these environment variables (which you should be) then be sure to create these as User Environment Variables, rather than System Environment Variables. This allows Windows to protect these values and only give access to them when the specific user they pertain to is logged in. Also, it is recommended that you do not store your password in SSPWD under Windows 95. Figure 1 shows the environment variables after they have been set.

Figure1. User Environment Variables dialog.

Using environment variables doesn’t stop there. Setting SSUSER gets you around needing to specify a login, but what about specifying the VSS Database you want to connect to? If the database you need to connect to is on a share (which is most often the case among teams of developers) then you can configure an environment variable named SSDIR to contain the path to the VSS database (the srcsafe.ini file).

Gotcha #1: For those of you using Visual Studio.NET, you might experience problems using the environment variables. To solve this with Visual Studio.NET, go to Tools | Options | Source Control | SCC Provider to find options for setting the default login to be used.

Gotcha #2: If you decide to go with using the network name to allow users to be logged in automatically, make sure you use the VSS Admin tool to make each user’s VSS password blank. Since VSS doesn’t use the same password as the NT User, you need a blank password for this to work.

Take Advantage of Keywords

Keyword Expansion refers to the ability VSS has to replace certain sections of files with information relevant to the file such as the last time it was modified, who modified it or the date and time the last check in operation occurred. Typically, you will want to place the keywords in commented sections of code at the top of your source files so they do not affect compilation. Here is a quick table of all the VSS keywords and what information they provide.

Note: Keywords are case-sensitive so be sure to capitalize them properly.

For example, if you added the following to a C# source file:

//VSS Keyword information

//File last modified by: $Author: $

//on $Date: $

VSS would replace it with

//VSS Keyword information

//File last modified by: $Author: Jason Mauss $

//on $Date: 06/28/2003 10:30:15 AM $

As you can see, this takes the pain out of keeping track of who has done what and when. If you would like to format the keyword data into nice blocks of information you can also use the double colon format which looks like:

$Date::        $

or

$History::     $

This tells VSS that you want the dollar sign (the end of the line) exactly at that position, and it will align or truncate the information so they you can create more readable columnar information.

Keyword expansion can also come in handy with web files (html, asp, jsp, etc.). Using the JustDate keyword, you could automate modifying the text in a page footer that tells the last time the page was modified. For example, you could place the following in a file:

This page last modified on <!--$$JustDate:--!> <!--$-->

And upon check in, VSS would replace that text with

This page last modified on <!--$$JustDate:--!>6/28/03<!--$-->

And upon each subsequent check in, the file would be updated with the current date. For those of you wondering if you can create your own custom keywords for expansion, unfortunately it is not supported in the latest version of VSS.

Tips for Web Projects

For web developers using VSS to maintain their various web files, a few features specific to web projects are available. These are Check Hyperlinks, Create Site Map, and deploy. All of these features can be found under the “Web” menu in VSS Explorer.

The Check Hyperlinks features does exactly what it sounds like it does. For all the files in your web projects that contain an anchor tag with an href attribute “<a href=www.mysite.com>mysite</a>” VSS will validate the links. It can also check links external to your web project on the web. After checking all the links, VSS will display a dialog telling you which files had errors, links that seem to be invalid, and links found but, not checked. This features comes in handy when you are ready to deploy your web files to a web server or have had your site running for some time and want to check for stale or expired links in your HTML.

The Create Site Map feature allows you to use VSS to generate an HTML file that contains links to pages in your web project. The page generated by VSS is fairly crude but, it can save you some time collecting links to all your pages.

The Deploy feature allows you to copy your files to a folder or FTP location that is configured on a per-project basis before the deploy command is used. This allows you a quick and easy way to copy the new changes to web files to a live web server. When using this feature be sure that all developers have write permissions to the folder or access to FTP is configured properly on your network.

Best Practices for VSS Administrators

Sometimes ease of use can be misleading. For example, VSS is pretty easy to install and it’s very simple to set up a VSS database. What you should know though, is that VSS is not optimized for performance out of the box. Here are some things you should be aware of so that you can get better performance out of VSS.

1. In the ss.ini or the srcsafe.ini file (the VSS database) set the Diff_Ignore (PC) value to c-e-s-w which will tell VSS not to ignore end-of-line differences, which will speed up file comparisons.

2. Set the CP_OnSelection value to NO.  This is incredibly useful for users accessing VSS over a remote connection. Why? Normally whenever you click on a folder (a project or project grouping level) VSS performs a selection operation, which can take a while over a slow remote connection. By setting CP_OnSelection to no, users can drill down in the project hierarchy and just double-click or hit Enter when they find the folder they want to actually select, not having to wait a while for each level they expand.

3. Set the path of your temporary folder to a local temp folder (like C:\Windows\Temp) in your SS.INI file. This will have VSS write temporary files locally instead of perhaps to a network drive.

4. Know which features you need and disable ones you don’t. Here are 4 features that are costly that should be disabled if not needed:

• Shadow Folders
• Journal Files
• Project Security System
• Keyword Expansion

5.  Run the Analyze.exe utility against your VSS database about once a week to ensure the integrity of the database. Analyze.exe will scan the VSS database for errors and fix them if possible. Find these errors and fix them before your developers come across them. You could even create a batch script and schedule a job that runs Analyze.exe at a regularly scheduled interval.

Note: Make sure all users are logged out of VSS before running Analyze.exe. Files can be checked out however, during this process.

6. Use the SSARC.exe utility regularly to archive and compress part or all of your VSS database for backups. Using SSARC.exe will reduce the amount of space required to backup your VSS database. This is most important for large scale users of VSS, who likely have more than one database.

Conclusion

As you can see, there is a lot you can do with VSS, if you know what’s there and how to use it. If you manage a team of developers I urge you to put them through some kind of training so they don’t have to learn how to use VSS and its features the hard way.  Taking time to configure VSS properly can also help you tighten your development cycle in terms of managing the build process and web application deployment. With a little planning up front, you can save yourself headaches later on.