Microsoft Corporation
May 1995
Professional software development requires a streamlined process for managing changes to the source code for each application under development. Microsoft® Visual SourceSafe™ records the change history at the system, project, and file levels, allowing you to safely distribute development among multiple programmers, track changes, and recover old versions of individual files or of an entire application.
Code is a precious resource. To protect it, most developers safeguard files against unauthorized changes and unexpected failures using some system of version control. These systems can vary from gentleman's agreements about commenting changes and storing old versions to sophisticated software systems that track changes and histories automatically.
Most of these source control systems work well for individual source files. However, almost all of them fail to establish relationships between files. This can pose quite a problem in the Microsoft® Windows® environment, where a single application can consist of multiple executable files and dynamic link libraries built out of many different 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.
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 need to write a batch file or specify wildcards on the command line.
Microsoft Visual SourceSafe stores files in a central database on the network, rather than on 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 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 and 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. So 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 the project history to simplify these tasks:
Attempting these tasks with file-oriented systems can be an incredible chore and a frustrating impediment to software developers. Visual SourceSafe project-oriented version control streamlines the development process by making all of these tasks straightforward, as illustrated by the following scenarios.
Suppose that you are about to build a major application consisting of many separate 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 none of the files in the entire system is 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 quite a chore.
Visual SourceSafe, like other systems, can determine whether 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 who to talk to if you can't!). By simply executing a command on a project, Visual SourceSafe automates a previously tedious, manual task.
File history reports are available in all version control systems, including Visual SourceSafe. 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 did it, when it was done, and what comment was 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 with a standard version control system, you would generate a history report on a likely-looking file, see whether it had changed recently, and look through the changes. If you don't find the bug, you 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 was actually adding or deleting 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, it 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 last week. This can save you a lot of time and help you avoid dead ends.
By tracking project history, Visual SourceSafe allows you to quickly recreate previous versions of an entire application. This can help you resolve bugs reported from previous shipped versions to make sure they were fixed in the version currently 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 do this with a standard version control system, you either have to separately archive the sources of each released version of the application or track the specific file versions for each release. Either way, restoring the correct source files for a previous build becomes a tedious, manual process—a task that is likely to be put off or delayed.
Most applications are developed around a common base of core code. These files are used over and over again in many different 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 managing the organizational issues. You have to remember which applications are using each file and propagate every change to all the appropriate places. This is only a minor annoyance when five applications are reusing one file; but when twenty applications are mixing and matching fifty different reusable files, you've got a problem!
A standard version control system can't help at all with this problem because one file can exist simultaneously in many different projects. But Visual SourceSafe can automate it completely. 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 may "freeze" the version of a file to avoid introducing errors while another development team works on the reused code.
To take a common example, suppose that you have a single source file that contains many different 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.
Another common source control problem concerns clients who want applications customized to meet their specific needs. Essentially, you have many different applications that share almost all of the same source files. Using 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.