The Microsoft® Visual SourceSafe 5.0 version-control system is the latest edition of Microsoft Corp.'s award-winning solution for managing software and Web site development. Fully integrated with the Visual Basic® programming system, Visual C++^® development system, Microsoft Access, the Visual J++" development tool, the FrontPage" Web authoring and management tool, and the Visual FoxPro" database management system, Visual SourceSafe provides easy-to-use, project-oriented version control. Visual SourceSafe works with any type of file produced by any development language, authoring tool or application. It enables users to work at the file and project levels while promoting file reuse. Visual SourceSafe enables team development with its project-oriented features aimed at increasing the efficiency of managing the day-to-day tasks associated with team-based software and World Wide Web site development.

The market for version-control systems such as Visual SourceSafe has never been better. Traditionally, only software developers have used version-control systems to manage their source code. The Internet, however, has created an opportunity for version-control products to become a critical element of most Web site development projects. Why? Web sites are much like development environments. They contain many files that are frequently updated by users. As Web sites are built, administrators who encounter bugs often can benefit from the audit trail that version-control systems provide. The team coordination problem associated with software development is magnified when developing Web sites. Typically, Web sites experience many updates over time, and the sites are developed by diverse teams of webmasters, graphic artists, writers and marketing communications specialists. The Web site development environment can quickly become unmanageable as team members inadvertently lose files, break links, or overwrite other team members' work-all without the safety net of version control.

Leading-edge corporations developing Web sites have already realized the need for version control in their Web site development environment. In fact, some of the content at the Web sites for Microsoft, SPRYnet (CompuServe's Internet division) and MetaBridge Inc. is managed today using Visual SourceSafe. White papers describing how Microsoft and SPRY use Visual SourceSafe to manage Web site content can be found in Appendix A and B of this reviewers guide, respectively.

Microsoft recognized the need for version control of Web sites and added specific Web features to Visual SourceSafe 5.0. This reviewers guide outlines those features and many others that will help install Visual SourceSafe in 1996 as a leading version-control system for the Windows^® operating system.

Key Features of Visual SourceSafe 5.0

New Features of Visual SourceSafe 5.0

Visual SourceSafe 5.0 introduces many new and exciting features for traditional software developers as well as webmasters and Web administrators. The major features in version 5.0 are described here.

Web Features

Deploy. The Deploy feature gives users a way to publish their Web projects to a live Web server each time they are updated.

Check Hyperlinks. The Check Hyperlinks feature helps users find broken links in their Web project by parsing the .html file, checking each internal link and reporting the results of the test to the user.

Site Map. Use the Site Map feature to generate a site map based on a collection of Web pages stored in Visual SourceSafe.

The following screen shot shows the Visual SourceSafe Explorer interface. The left pane of the Explorer displays the product's project tree, while the right pane displays a selected project's contents. The Visual SourceSafe Explorer indicates Visual SourceSafe-based Web projects with a blue globe icon on the project folder.

Execute new Web commands by selecting a Web project in the Visual SourceSafe Explorer and clicking the Web menu.

Integration with FrontPage 97. Visual SourceSafe 5.0 integrates with FrontPage 2.0 via the new OLE automation interfaces. Users of FrontPage can now easily move their Web projects under version control.

Users define a Visual SourceSafe-based Web project in FrontPage by selecting the Tools/Web Settings menu item.

Once a FrontPage-based project is under source code control, FrontPage takes care of updating Visual SourceSafe accordingly. For example, if you create a Web site that contains a blank page and add it to Visual SourceSafe, you can check out the blank page by selecting the Check Out command in the Edit menu in FrontPage. Now, in the FrontPage Editor, add a few images and text to your page. When you save your changes, FrontPage will automatically add the new image files to Visual SourceSafe and check them out. As dependencies among your Web pages change, FrontPage is smart about "talking" to Visual SourceSafe and making sure that the information is updated in the Web contents stored in Visual SourceSafe.

Integration with Visual J++. Are you a Java" developer? If so, and if you are using Microsoft Visual J++, you can easily use Visual SourceSafe to manage your Java Applets via the integration of Visual SourceSafe with Microsoft Developer Studio. In addition to the many SourceSafe commands that are available as menu items in the Developer Studio integrated development environment (IDE), Visual SourceSafe integrates into your project window so you can easily see which files are checked out. In addition, Microsoft has included many helpful dialog boxes that will prompt you to check out a file before you start your work or aid you in adding an existing project to Visual SourceSafe.

Additional Features of Visual SourceSafe 5.0

Visual Merge. Control merges rapidly and easily with point-and-click editing.

When merging file changes, Visual SourceSafe looks for conflicts. If any are found, you can view them via the side-by-side visual merging dialog box. With each conflict highlighted, it is easy to choose the appropriate changes while viewing the resulting merged file in the bottom pane.

Project Difference. The Project Difference environment keeps each user in sync with the rest of the project development team by comparing the user's personal working directory with the corresponding shared project in Visual SourceSafe.

Any differences between the user's working directory and the server projects can be instantly identified and resolved in a number of ways.

Open Multiple Databases. If you need to access files stored in multiple repositories in Visual SourceSafe , now you can switch on the fly.

You can define the databases in Visual SourceSafe that you visit most often and then simply select the Open/SourceSafe Database menu option. Next, select the database that you want to access, then click the Open button. That's all there is to it.

Integration With Microsoft Access 97. Visual SourceSafe is now integrated with Microsoft Access 97, giving Microsoft Access users the ability to version Microsoft Access components from inside their environment.

Commands for Visual SourceSafe can be found in the Tools menu, or, if you prefer, you can use the new dockable toolbar propagated with many of the most popular Visual SourceSafe commands.

Integration With Visual Basic 4.0 or Later

The integration of Visual SourceSafe with Visual Basic has been designed to let you develop applications as you always have and take advantage of added functionality without additional complexity. The integration between Visual Basic and Visual SourceSafe represents a comprehensive approach aimed at enabling the most common source code control functionality inside the Visual Basic-based design environment. The following scenarios demonstrate the integration between Visual SourceSafe and Visual Basic.

A developer writes an impressive new application with Visual Basic and places it under the control of Visual SourceSafe. Other developers learn about the application and want it. In Visual Basic, on the Add-Ins menu, developers click SourceSafe, click Open New SourceSafe Project, and choose a project. This command brings the project down to their local hard disks and makes the new project their current project in Visual Basic.

A developer adds an important new file to an existing project. Other developers who are already working on the project with Visual SourceSafe regularly use the Get command to see if anything new is available. When they use the Get command to get the entire project, they get the new file and a new version of the project file in Visual Basic containing references to the new file.

You can enable source code control after you create a new project, or you can place an existing project under source code control. When you enable source code control in Visual Basic, you will notice changes to the Visual Basic interface that place the commands of Visual SourceSafe within easy reach.

When you open a project that is under the control of Visual SourceSafe, you activate the Visual Basic Tools menu choices in Get, Check Out, Check In and Undo Check Out. When source code control is not active, these commands are disabled.

The command called SourceSafe on the Add-Ins menu contains additional choices when source code control is enabled. Without source code control enabled, the only choices under SourceSafe are Open Visual SourceSafe Project, Run Visual SourceSafe, Add Project to Visual SourceSafe, and Options.

When source code control is enabled, additional commands are available in the Add-Ins menu. These choices are commands that interact directly with Visual SourceSafe without requiring you to leave your Visual Basic environment. For instance, the Show History command displays the history of projects or files under the control of Visual SourceSafe.

Integration With Visual C++

The integration of Visual SourceSafe with Visual C++ is similar to its integration with Visual Basic. You perform a client installation of Visual SourceSafe after installing Visual C++ to enable source code control. When you start Visual C++, you can access the functionality of Visual SourceSafe, as well as Visual SourceSafe itself, through Visual C++. In addition to using the menus to access Visual SourceSafe commands, you can access context menus in Visual C++ file and project panes using a right mouse click. The commands available in the context menus depend on the pane in which the menus are activated.

OLE Automation Interfaces. OLE automation gives you programmatic access to Visual SourceSafe commands and events from your Visual Basic- or Visual C++-based application. OLE automation documentation and code examples may be found on the Web site for Visual SourceSafe at http://www.microsoft.com/ssafe/.

Archive Utility. Earlier versions of the product offered no way to archive parts of SourceSafe databases. The only way to free up space was to destroy a file or project. Furthermore, there was no way to move information between databases. The archive utility is a separate command line utility that allows you to do the following:

• Archive a file or project out of the database into a special compressed file, then restore it later with its history, Share Links and other information intact
• Archive specific versions of a file-for instance, "all versions prior to 3.1"-thus freeing up the space they use in the database, and restore them to the database later
• Archive a file, project or project tree from one database and restore it into a different database

Administrator Lockout. When an administrator wants to back up SourceSafe database, archive projects or upgrade the executables, he or she needs the ability to lock everyone else out of Visual SourceSafe. In earlier versions of visual SourceSafe, locking out had to be performed the old-fashioned way-walking around to everyone's computer and saying "Stay out!" In larger organizations, this task is difficult. The new lockout feature solves this problem.

Edit Command. Microsoft has received many requests for users to be able to double-click a file in the Visual SourceSafe Explorer and be given the option of automatically checking out the file and bringing it up in their editor. This option has been added in version 5.0.

Cloaking. The Cloaking command allows users to ignore selected projects or files. In large nested projects, users may not want to Get the entire project to their working directory. Cloaking allows them to ignore projects or files that don't interest them.

Version-Control Primer

Visual SourceSafe is typically installed on a network server. In this central location, Visual SourceSafe stores all your files, represented as logical project hierarchies. Use the Visual SourceSafe Explorer to navigate and select the files and projects you want to work with.

Figure 1, which follows, interprets the general way you would use Visual SourceSafe.

Visual SourceSafe stores project contents as Read Only for purposes of ensuring the integrity of your files. If you want to edit a file stored in Visual SourceSafe, you must first Check Out the file. When you check out a file, a read-write copy of the file is placed in your working directory. Before you check out files, you must first set up a working directory, usually on your C:\ drive. Working directories tell Visual SourceSafe where to place files when you exercise a Check Out or Get command.

Check out a file from Visual SourceSafe, use your favorite editor or design environment to make your changes, save them, then check the file back in to update the repository in Visual SourceSafe. Visual SourceSafe retains an audit trail of both the file and the project as you check in and check out files and projects. Reverse deltas of the file are retained for quick and efficient access to your files. Reverse delta versioning means that only the latest copy of the file is being stored in full; the deltas, or changes, are also stored so that Visual SourceSafe can rebuild older versions of your files and projects.

Fig. 1. The general process for using version-control products

The Visual SourceSafe Explorer

Many of the actions described above take place in the Visual SourceSafe Explorer. The Visual SourceSafe Explorer is modeled after the Windows 95 Explorer for maximum ease of use and logical representation of your project contents.

The left pane of the Visual SourceSafe Explorer displays a list of the projects under version control. The project tree allows the user to create an almost unlimited hierarchy of projects and subprojects. When a user selects a project, the right pane displays all the files that are contained in the selected project. The Visual SourceSafe Explorer provides information about the status of files, as well as toolbars and menu bars for easy access to Visual SourceSafe commands. Users can also change column widths, sort files by various criteria, and view real-time information about the status of files and projects.

A typical Web site- or software-development team includes programmers, writers, testers, managers and architects. Any development environment, however, also requires the services of individuals not usually found on a development team. These individuals include the following:

• A librarian to check files in and out, keep them where they belong, and organize and store important documents
• A historian to record all file activity
• A security guard to make sure files go only to those with the proper access rights assigned to them

Visual SourceSafe carries out the tasks of a librarian, historian and security guard through many of the services that are described in the following sections. Moreover, Visual SourceSafe aids project managers and developers by offering many project-oriented features that automate manual tasks associated with advanced software development.

Visual SourceSafe Library Services

Perhaps the most important function that Visual SourceSafe serves is stated in its name-keeping source code safe. Working with files in Visual SourceSafe is like checking books in and out of the library. The advantages of keeping your files safe within Visual SourceSafe include the following:

• Preventing accidental deletion of information or files. When a development team works with Visual SourceSafe and checks in files with changes or additions, the changes cannot be lost accidentally. Visual SourceSafe stores all changes to a file.
• Organizing files into a nearly unlimited hierarchy of projects and subprojects. As your project team grows in size and stature, Visual SourceSafe grows with you, providing salability without added complexity. The disk size of your database server for Visual SourceSafe is the only limitation to the number of projects you can store in Visual SourceSafe.
• Checking files in and out easily and adding comments to describe what you have done. You can take files out and replace them with the click of a button. Visual SourceSafe lets you describe precisely what you intend to do or what you have done to a file or project, with room for as many as 32,000 characters in each comment for most commands.
• Developing cross-platform applications. Visual SourceSafe simplifies the development of applications in cross-platform environments by allowing the developer to maintain a single code base. Visual SourceSafe supports the Windows 95 and Windows NT^® operating systems (for Intel, PowerPC, Alpha and MIPS platforms), and will support Macintosh and UNIX platforms via third parties. Versions of Visual SourceSafe for UNIX are available from Mainsoft Corp. The Macintosh version of Visual SourceSafe is available from Metrowerks Inc.
• Visual SourceSafe stores any type of file-text files or binary files-including source code, .html, scripts, active components, Microsoft Word documents, and spreadsheets.

Visual SourceSafe History Services

As developers make changes to files and check them into the repository in Visual SourceSafe, Visual SourceSafe maintains detailed logs of changes made on a file and project level. Visual SourceSafe History Services enable developers to do the following:

• Track versions, archiving and the changes that users make to files, so older versions of the files are readily available for bug fixes and other purposes
• Track date and time of changes to all files as they are updated
• Create reports on activity in a file or project
• Create journal files, with records of all comments that each user records
• Display and report differences between two version of a file or project

Visual SourceSafe Security Services

Controlling access to files is a critical component of maintaining source code. Each time a user executes a command, Visual SourceSafe checks the user's privileges. Visual SourceSafe contains a password-protected administrative program that enables the administrator to set both default and custom rights on a per-project basis. Five levels of rights are available to assign to the users, as shown in the illustration that follows.

Fig. 2. The security options available to administrators in Visual SourceSafe

Rights Description

No access Users not assigned rights to a given project may not view or edit files.

Read (R) Users assigned Read access can use and look at files by executing commands such as View and Get

Check Out (C) These Users have the right to modify files. These rights are often assigned to quality assurance engineers and technical writers. Check Out rights include Read rights.

Add (A) Users can modify the contents of a project using the add, delete and rename commands. Users assigned Add rights also have Check Out and Read rights.

Destroy (D) Users assigned Destroy rights can roll back, purge or destroy project contents. Destroy rights also include Add, Check Out and Read rights.

Conclusion

Microsoft Visual SourceSafe is the best way to manage software and Web site development for any size team. Fully integrated with Microsoft Access, FrontPage, Visual Basic, Visual C++, Visual J++ and Visual FoxPro, it provides easy-to-use, project-oriented version control.

Visual SourceSafe fills a critical need in any team-based Web authoring or software development environment. Enhanced integration with Microsoft Access, Visual Basic, Visual C++, Visual J++, FrontPage and Visual FoxPro provide easy accessibility to common version-control functionality from inside the development or authoring environment. Store all your project components inside the repository in Visual SourceSafe. Use Visual SourceSafe to version source code, .html files, scripts, active components, Microsoft Word documents, or spreadsheets. In addition to basic version-control functionality, Visual SourceSafe provides advanced functionality that includes branching and merging to support customization and parallel development. Even the most advanced features found in Visual SourceSafe are easily executed thorough the Visual SourceSafe Explorer interface. Increase efficiency and protect your source code and Web site contents for tomorrow using Visual SourceSafe today.

The Competitive Landscape

The following table compares the features of Microsoft Visual SourceSafe with those of Intersolv's PVCS Version Manager, MKS Source Integrity and Softool CCC/Manager.

PC-Based Version Control

Competitive Feature Matrix

Appendix A: What Makes Visual SourceSafe Unique?

Most source-control systems work well for individual source code files. However, almost all of them fail to establish relationships between files. This can pose a significant problem in the Windows-based environment, where a single application can consist of multiple executable files and dynamic-link libraries built out of many source files, which in turn may be reused among many other applications. Today it is as important to manage the relationships between source files as it is to protect the contents of the source files themselves.

Microsoft Visual SourceSafe version-control software solves this problem by combining the tasks of project management and source control. By focusing on projects as well as source files, Visual SourceSafe provides an elegant solution to problems not easily solved using standard, file-oriented source-control systems.

Organizing Software Development by Project

To understand the benefits of project-oriented source control, simply compare it to a file-oriented system. A standard version-control system (such as the UNIX utility RCS) is essentially a collection of tools that operate on individual files, controlling file access and updates and comparing previous versions. To operate on a group of files, you write a batch file or specify wildcards on the command line.

Visual SourceSafe stores files in a central database on the network, rather than in an ordinary DOS directory. At the system level, this database appears as a black box. When viewed through Visual SourceSafe, however, the database is seen to contain all of your source files and histories organized into project hierarchies.

When you retrieve a file, Visual SourceSafe marks the file as checked out to you in its database, then allows you to make changes to the file on your machine. When you check the file back in, Visual SourceSafe updates its database and changes the file's access privilege on your machine back to read-only.

How is this any different from file-oriented source control? With each change, the Visual SourceSafe database records and tracks project information not available to file-oriented systems. Each time a file is added, modified, shared, moved or deleted from a project, Visual SourceSafe updates both the file and the project's history. You can use project history to simplify these tasks:

• View the status of all the files in a specific project and all subordinate projects before building
• Zoom in on a specific file change that might have caused a bug in a build on a certain date
• Re-create any previous version of an entire application
• Maintain source files that are shared among many applications
• Determine which projects are affected by changing a file that is shared among many applications
• Manage client-specific versions of a general application

Attempting these tasks with file-oriented systems can be an incredible chore a frustrating impediment to software developers. The project-oriented version control in Visual SourceSafe streamlines the development process by making all of these tasks straightforward, as illustrated by the following scenarios.

Preparing for a Build

Suppose you are about to build a major application consisting of many components. Before you start the build, you want to make sure that no one is revising code at the last minute; or, in version-control terms, that no files in the entire system are checked out.

A standard version-control system provides you with a tool for determining whether a file is checked out. Your job is to run this utility on every file in every directory that is being used for the build. Batch files and wildcards make the task easier, but in a complicated system, it can still be a big chore.

Visual SourceSafe, like other systems, can determine if a file is checked out. But it can also create a higher-level report: a list of all the checked-out files in a project. This feature becomes even more powerful when used recursively to include all subprojects in the current project. Visual SourceSafe checks every file in every relevant project and generates a list of every checked-out file. You know immediately whether you can proceed with the build (or whom you need to talk to if you can't). By simply executing a command on a project, you enable Visual SourceSafe to automate a previously tedious, manual task.

Pinpointing Regressions

File history reports are available in all version-control systems, including Visual SourceSafe. A file history lists each version of a file, from the most recent to the oldest, with information such as what happened to the file, who modified it, when the changes were made, and what comments were made.

Despite their usefulness, file histories have severe limitations. For instance, suppose a feature that was working correctly last week breaks in this week's build of your application. Obviously, someone introduced this bug recently, but in what file?

To tackle this question with a standard version-control system, you would generate a history report on a likely looking file, see if it had changed recently, and look through the changes. If you didn't find the bug, you would pick another file to check, and so on. You might go through every file in the system this way and never find the critical change because the change actually added or deleted a file, which standard version-control systems don't track at all.

With Visual SourceSafe, you generate a report on the project itself. For instance, Visual SourceSafe might report that COMMON.BAS was just modified; before that, OPENALL.FRM was changed; before that, FILESUPP.BAS was added to the project; and so on. Visual SourceSafe collates the changes that you would otherwise have to sort through manually, enabling you to view the order of changes over the past week. This can save you a great deal of time and help you avoid dead ends.

Re-Creating Previous Project Versions

By tracking project history, Visual SourceSafe allows you to quickly re-create previous versions of an entire application. This ability can help you resolve bugs reported from previous shipped versions, to make sure they were fixed in the version under development.

For instance, suppose a client reports a printing problem in version 2.03 of an application. That version of the application may have included version 10 of one file, version 15 of another, and so on-but you don't need to worry about that. By requesting the specific version of the project from Visual SourceSafe, you can restore a complete, local copy of the application's source files used to build version 2.03.

To restore the proper source files with a standard version-control system, you would have to either archive the sources of each released version of the application separately, or track the specific file versions for each release. Either way, restoring the correct source files for a previous build becomes a tedious, manual processa task that is likely to be put off or delayed.

Maintaining Reusable Code

Most applications are developed around a common base of core code. These files typically are used over and over again in many applications and usually evolve over time, receiving bug fixes, performance improvements and new features. The benefits of reusing existing code are enormous, but so are the headaches when it comes to managing the organizational issues. You have to remember which applications are using each file and propagate every change to all the appropriate places. This task is only a minor annoyance when five applications reuse one file, but when 20 applications mix and match 50 reusable files, you have a problem.

A standard version-control system can't help at all with this problem. Visual SourceSafe can automate it completely, however, because one file can exist simultaneously in many projects. Within its database, Visual SourceSafe stores each file only once. Each project that contains a file has a pointer to the location of the file in the database. All versions of the file are available to each project, and a project can freeze the version of a file to avoid introducing errors while another development team works on the reused code.

To cite a common example, suppose you have a single source file that contains many procedures for printing reports. In Visual SourceSafe, each application that needs to print reports would share the file. If you find a bug, you update the file from any project the change is instantly propagated to every project that shares the file. Then Visual SourceSafe can report on which projects share the file, so you know which applications are affected and may need to be rebuilt.

Creating Client-Specific Versions

Another common source-control problem concerns clients who want applications customized to meet their specific needs. Essentially, you have many applications that share almost all of the same source files. When you use standard source-control tools, tracking changes and keeping builds straight can take more time than the programming. Using Visual SourceSafe, you create a project for each new client, indicating which files are shared and which files are unique. When you work on a project, client-specific changes stay with the current project, and changes to shared files are propagated to all client versions.

Appendix B: Managing Web Content Using Visual SourceSafe

Abstract

More than 10,000 documents make up the pages of the Microsoft corporate Web site, http://www.microsoft.com/. During the course of this year, the number is expected to climb to more than a million documents, written by hundreds of people. Maintaining a Web site of this magnitude is not simply a matter of writing HTML syntax; it is a large-scale management and coordination task. The team dedicated to Visual SourceSafe has developed an approach based on the existing content-management capabilities in Visual SourceSafe to automate and securely track the many changes that occur within the group's Web content.

Since the original publishing of this appendix in January 1996, other groups at Microsoft that submit content to http://www.microsoft.com/ have started using Visual SourceSafe to manage their Web content. The Web pages for Visual Basic, Visual Basic, Scripting Edition (VB Script), Visual FoxPro, Internet Control Pack and Visual SourceSafe are all managed using Visual SourceSafe. This appendix outlines a process that uses the sharing, keyword embedding and shadow directory capabilities in Visual SourceSafe to provide a solution to Web content management today.

Problem Definition

Many people work together to create, support and update material for the Microsoft Web site. Combining a large number of documents, people and updates creates a complexity that is not easily managed without the help of an automated solution.

Figure 3 offers an example of a process used for submitting and updating Web page content for inclusion in the Microsoft Web pages without the help of Visual SourceSafe.

• The process begins with a team of content developers collecting and authoring documents that are written natively in HTML or converted using Internet Assistant for Microsoft Word. These pages are stored in logical directories on a network server to which each member of the team has access.
• As modifications are made to the existing Web pages, the changed files are copied to another server that is managed by another group of people, who test the pages submitted by many product groups.
• If bugs are found in the HTML files received from a group, the testing team communicates this back to the product team, which resolves the problem and posts the Web page back on the testing server.
• Once tested and debugged, the directories are copied to the main Microsoft Internet Information Server, where the external world can link to Microsoft via the Internet.

Fig. 3. The process for submitting and updating content for the Microsoft Web site

One other factor complicates this process. In addition to the external Web site, Microsoft has an internal Web site. Each product group creates and maintains its own pages for the internal site; these pages do not go through the same centralized testing process. For most product groups, the pages on the internal Web site are the same as the pages on the external Web site, with the addition of information that is proprietary or interesting only to other groups at Microsoft. Thus, when a product group changes a page, it must do its own testing first, then copy that page to the central testing group for the World Wide Web and to its own server for the internal Web site. Some pages, however, are copied to only one site.

The challenge faced by Microsoft, and other teams or corporations instituting similar systems, is to manage this rapidly expanding body of information. HTML writers should focus on creating content, testers should focus on testing links as rapidly as possible and getting updated information onto the server, and all of the parties concerned should spend as little time as possible asking questions such as "Who worked on this document?" or "Where should I copy it to?" or "What happened to the version that worked?" The group dedicated to Visual SourceSafe uses Visual SourceSafe features such as shadow directories, keyword expansion and sharing today to automate file tracking and versioning, keeping the system manageable.

Organizing Web Pages into Projects

A Web site is organized as a main directory, with a starting page (usually called DEFAULT.HTM), and other pages and subdirectories stored in a directory tree on the Web server. The first step in using Visual SourceSafe is to copy all your files into a Visual SourceSafe project tree that mirrors your directory tree. (This can be done as easily as dragging a folder from the Windows 95 Explorer into the Visual SourceSafe Explorer.)

For instance, the main Web page for Visual SourceSafe looks like the one in Figure 4.

Fig. 4. The main Web page for Visual SourceSafe

If users click, for instance, Introducing Microsoft Visual SourceSafe 4.0, they jump to a list of introductory topics, papers and so on for each of the other buttons.

On the Web server, the main URL http://www.microsoft.com/ssafe/ is represented by a directory containing a number of files. Each topic in the preceding list is a subdirectory, and the white papers are files in those subdirectories.

In Visual SourceSafe, these relationships are represented by a SourceSafe project tree that mirrors the directory hierarchy exactly. Figure 5 shows a screen from the Visual SourceSafe Explorer and illustrates the database used by the Web team associated with Visual SourceSafe.

Fig. 5. The Visual SourceSafe Explorer window

Under External Web (which represents the main URL directory) is a project called Introducing Microsoft Visual SourceSafe 4.0. This project contains files that represent the pages the user reaches from that jump. As the preceeding screen illustration shows, one file-SOTHER.HTM-is checked out by a user named Stevenj. When Stevenj clicked Check Out for this file, a copy was made in his local working directory on his computer. He is now editing this file and testing it locally. When he completes his changes, he will check the file back into Visual SourceSafe, thus making his changes available for the rest of the team.

The benefits of using Visual SourceSafe in this way are the same benefits that version control has always offered to professional developers. Visual SourceSafe helps coordinate the team by keeping track of which people are working on which files. Visual SourceSafe also keeps track of old versions of all the files in a very disk-efficient way, making it easy to revert to an older state of a file or an entire project.

Sharing to Track Internal and External Web Sites

In addition to the external Web site project discussed previously, there is another project in Visual SourceSafe representing the internal Web site. Like the external Web site project, this project consists of a number of subprojects and files (not shown in Figure 5) that reflect the hierarchy of directories on the Web site for Visual SourceSafe. However, this project builds a completely different site-the internal Web site for Visual SourceSafe, which is available only to other groups at Microsoft. This Web site is hosted on a different server from the external Web site. In addition, some of the files between the two sites differ, although most are the same. When a developer modifies a file, that modification may affect one site, or it may affect both-and it is critical that the file get copied to the appropriate sites.

Sharing is the feature of Visual SourceSafe that automates tracking the simultaneous Web sites. Sharing simply means that in Visual SourceSafe, one file can exist in multiple projects at the same time. For instance, the file Top Ten.htm is used on both the external and internal Web sites-in both cases, the file exists in subdirectories called Introduction to Visual SourceSafe 4.0. In Visual SourceSafe, the file is shared between the Introduction to Visual SourceSafe 4.0 subprojects under both the External Web and Internal Web projects. Visual SourceSafe stores only one copy of the file internally-so whenever a change is made to this file in either project, that change is automatically reflected in the other project as well.

Note that in Figure 5, the icon for Top Ten.htm (multiple-document icon) is different from the one for SourceSafe Intro.htm (single-document icon). This difference reflects the fact that the former file is shared with other projects, while the latter is not. Thus, the developer who checks in Top Ten knows that his change will affect other projects. You can also ask Visual SourceSafe for a complete list of projects that share a file.

The benefit for developers of Visual SourceSafe, in general, is that they do not have to worry about multiple Web sites. They can change a file once and know that the change will propagate to both Web sites if it should, and that it will affect only one Web site if the file is used only once-automatically.

Shadow Directories for Testing and Deployment

So far, each developer is working in a local working directory on his or her hard drive, and the team is using the database in Visual SourceSafe as a shared repository. But nothing is getting copied to the Web.

The deployment step can be handled in two ways. First, it can be accomplished manually, through the Get command in Visual SourceSafe. This command can be used to copy an entire project tree to a specified directory tree. Hence, the External Web and Internal Web projects could be copied to their respective directories for the testing group and internal Web server, respectively, by using the Get command.

The team associated with Visual SourceSafe uses its shadow directory feature to help automate this process further. A shadow directory is a central directory on a server that always echoes the contents of a project. Hence, whenever a developer updates a file in a Visual SourceSafe-based project, that file is automatically copied to the shadow directory.

Making the shadow directory the actual Web server is not advisable. That method of deployment would increase network load on the Web server and, of even greater concern, would avoid the central testing process. However, the External Web project in Visual SourceSafe is shadowed to the drop point for the central testing team, and the Internal Web project is shadowed to the drop point for the internal tests. These drop points can act as miniature Web sites purely for testing purposes, and they can also be run through automated testing utilities. Either way, once they are approved, these directories can be copied to the actual Web servers.

Note at this point how much happens automatically when a developer clicks Check In. The file is copied from the working directory on the developer's hard drive, into the Visual SourceSafe-based project. If the file is shared, this change automatically affects both the internal and external projects. Then the new file is copied into the shadow directories for one or both of the projects, where it can be tested and deployed.

Fig. 6. Testing and deployment process

Keyword Expansion for Tracking

The final feature in Visual SourceSafe that is particularly useful for Web development is keyword expansion. Visual SourceSafe has the ability to embed certain version-control information directly into a text file.

As an example, suppose that a tester in the centralized group finds a broken link. That file will not get deployed to the central Web site. Instead, the developer must be notified so the file can be fixed. The new tracking problem is, how does the tester find and communicate with the developer?

The answer is easy if the developer puts the following line at the top of each HTML file:<!--$Header: $-->

The syntax $Header: $ is a keyword in SourceSafe. When the file is checked in, Visual SourceSafe automatically fills in the full project path of the file, the version number, the date and time, and the user who is checking it in. The resulting line might look like this:<!--$Header: $/Documents/External Web/DEFAULT.HTM, 4, 12/1/95, Stevenj $-->

The angle brackets, exclamation point and dashes at either end make this an HTML comment, which will be ignored by Web browsers. But the tester who finds the bug can contact Stevenj and specify the exact file (with the project path in Visual SourceSafe) and the version number that has the bug.

The Bottom Line

Visual SourceSafe helps automate the process of managing large, team-based projects. The product's file sharing, shadow directory and keyword expansion features, combined with the intuitive interface and project-oriented design make Visual SourceSafe a powerful addition to the environment of Web authoring teams. More information on Visual SourceSafe can be obtained on the Internet at http://www.microsoft.com/ssafe/ or by contacting Microsoft technical sales at (800) 426-9400 (United States only) or a local Microsoft reseller.

Microsoft, Visual SourceSafe, Visual Basic, Visual C++, Visual J++, FrontPage, Visual FoxPro, Windows, Windows NT and MS-DOS are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.

Java is a trademark of Sun Microsystems Inc.

The information contained in this document represents the current view of Microsoft Corp. on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

© 1996 Microsoft Corp. All rights reserved.