Microsoft Corporation
Updated September 3, 1996
Your project has grown. The number of programmers has doubled and the productivity has gone up by . . . oh, about 50 percent. Sometimes it seems as if you're actually getting less done than you did with a small team. What happened?
What you've just discovered is that larger products mean more complexity. As you scale up to a large team of developers working on a mission-critical application, a whole new set of questions arises:
You'll probably also find yourself spending more and more time doing source code "bookkeeping," which is why more programmers are getting less done!
Microsoft's solution to this problem is the project-oriented version-control system: Microsoft® Visual SourceSafe™ version 5.0. Some people associate older, UNIX-based version-control systems with bureaucratic overhead, but Visual SourceSafe actually helps you spend less time on code-management issues and more time programming. Two keys make this work: ease of use and the unique project-oriented architecture of Visual SourceSafe.
A typical Visual SourceSafe network consists of one centralized code database on a server and one or many individual developers' hard drives. The shared Visual SourceSafe database is where you store and track your code. The individual hard drives are where you edit and compile your code.
Figure 1. An example of a Visual SourceSafe network
Your hard drive is organized into a directory tree with a root called C:\ and subdirectories with names such as C:\DEV\NORWIND. The Visual SourceSafe database is organized in a very similar manner—into a project tree with a root called $/ and subprojects with names such as $/Source/NorWind.
If you are working on a project, you associate that project with a working directory on your hard drive. This is a user-by-user setting, so Joyce may have $/Source/NorWind in C:\DEV\NORWIND, while Mary may have it in D:\NW. The Visual SourceSafe project is common to the whole group; the working directories are individual to each developer.
Figure 2 describes four basic operations you use on a day-to-day basis to move code between a Visual SourceSafe project and your working directory.
Figure 2. Four basic file-moving operations
The Checkout command can work in two ways. To avoid editing conflicts, Checkout can be exclusive, allowing only one developer at a time to check out a file. Or, Checkout can allow multiple checkouts of the same file. Visual SourceSafe later helps you merge the various changes made by different developers.
If you've never used version control before, this may seem like a whole new level of complexity—one that you've been living fine without. But if you're working on a network, you've already been doing something like this. There may be a "master copy" of your source, used for builds. And there are almost certainly copies of the files on some developers' hard drives that they edit and compile. There must be some system for keeping track of who is working on a file and for reconciling changes if more than one developer modifies a file. So Visual SourceSafe gives you a faster, more guaranteed, and more automated way of doing something like what you've already been doing.
If you have used other version-control systems, much of the Visual SourceSafe model will look familiar. The big difference is the centralized code database, organized into projects. It can be disconcerting that your files don't "live" in directories at all, that you can't even see them without Visual SourceSafe. But Visual SourceSafe projects allow you to track your source code at a higher level than other systems allow. For instance, you can:
Experienced users find that the following tips act as good guidelines, although, of course, your own development environment and common sense are always the final arbiters.
Visual SourceSafe is not only for code. Documentation, Help files, graphics, dynamic-link libraries (DLLs), and even executable code can be stored in Visual SourceSafe. Storing a file enables you to keep track of who is working on the file and to keep track of old versions of the file.
For instance, a project in the Microsoft Visual C++® version 4.0 development system typically consists of a code directory, with a subdirectory named RES. There may also be other subdirectories where you keep files related to this project, such as documentation. Suppose you have a C:\DEV\AUTO directory with the subdirectories RES, DOCS, SPECS, and HELP. In Visual SourceSafe, you would create a project called, perhaps, $/Auto. Under it, you would create four corresponding subprojects: RES, DOCS, SPECS, and HELP.
This single point is perhaps the most common cause of confusion about Visual SourceSafe, and the confusion stems from the word "project." A Visual SourceSafe project is not a Visual C++ project or a Microsoft Visual Basic® project. It is a unit of organization, corresponding most closely to a Microsoft Windows® 95 folder.
A project, in the integrated development environment (IDE) sense of the word, is most commonly represented in Visual SourceSafe as a project tree.
Once you have learned Tip 1 and you're ready to migrate your directory structure perfectly in Visual SourceSafe projects, you are also ready for the one exception: sharing.
As you move toward object-oriented code, your goal is to be able to reuse more objects. But reused objects create a tracking problem. If you update a shared object, how do you propagate the changes to all the programs using that file? Whom do you notify of the change? Many companies solve this problem by creating a COMMON directory for all shared code, which makes it difficult to determine which files actually make up any given program.
If you have a directory structure that works for you, you can, of course, continue using it in Visual SourceSafe projects. But with Visual SourceSafe, one file can be in many projects at once. The file is stored only once inside the Visual SourceSafe database, with "pointers" to and from each sharing project. So, when you update the file in one place, the change propagates to all relevant projects. (There are ways to block this propagation, either temporarily or permanently, but they are beyond the scope of this article. For reference, these operations are known in Visual SourceSafe as pinning and branching.)
Introducing Visual SourceSafe into your development environment is easy if you simply mirror your directory structure in a Visual SourceSafe project structure. Over time, you may find yourself moving away from a perfect mirror by using features such as sharing that make projects more flexible than directories. But in many cases, this does not happen until you have been comfortably using the product for months.
Most developers find that Visual SourceSafe allows them to work in a way that is natural, at both the high level of programs and systems and at the lower level of individual files. This ultimately leads to more development in less time—with a lot fewer headaches.