Using Visual SourceSafe 5.0 with Visual FoxPro 3.0

Microsoft Corporation

October 1996

Abstract

Microsoft® Visual FoxPro™ 3.0 has the capabilities for creating large enterprise-wide database applications. Its object orientation and client-server capabilities allow it to be used on projects that encompass multiple developers. In such situations, being able to place the source code under version control becomes a necessity. This article discusses using the version control features of Microsoft Visual SourceSafe™ in Visual FoxPro 3.0 application development efforts. The information in this article should be sufficient to get you started with version control using Visual SourceSafe.

What Is Version Control?

Microsoft  Visual SourceSafe™ provides both the control capabilities that keep one developer from overriding another's work and the versioning capabilities that allow anyone to recreate an earlier version of the software, as needed. When multiple developers will be working on one project, there should be a mechanism that ensures that only one developer will be working on any given piece of source code, ensuring that one developer does not overwrite another developer's work. Additionally, it often becomes necessary to go back to a previous version of a piece of source code in order to recreate an old build, create a new branch of the application, or to review a design decision.

Figure 1 shows Visual SourceSafe working with a Microsoft Windows® 95 Explorer type of interface.

Figure 1. Visual FoxPro application source as shown in Visual SourceSafe

As you can see, the left side of the window shows a project hierarchy, represented by folders, while the right side shows the files in the currently selected folder. Four files in the above window are currently checked out (shown by the checkmark on the file icon) and are editable by the person who checked them out (Alang), while the two highlighted text files are not checked out and cannot be edited.

It is important to note that the Visual SourceSafe Explorer uses the folder representation to show projects, not directories. This representation will serve you well if you consider this when designing your application. A well-designed project will map in a way that supports the project and the software. A project will be mapped well if it is designed as laid out in the Microsoft Visual FoxPro® Project Manager. If the SourceSafe project closely maps to the Visual FoxPro Project Manager, the consistency will decrease the learning curve.

As files are checked in and out by developers, Visual SourceSafe records what modifications are made, and allows the developer to describe each change, giving us a history of the system. Visual SourceSafe also allows developers to tag a set of files with a version number, allowing the recreation of a particular version of a system. These tags are called labels. When you label a project, the labels are inherited by the files contained in the project.

With this basic understanding of Visual SourceSafe in mind, we'll look at the issues involved in using Visual SourceSafe with Visual FoxPro.

Common Issues in Using Visual SourceSafe with Visual FoxPro

Setting up Visual SourceSafe with Visual FoxPro

When you install Visual SourceSafe 5.0, it includes support for Visual FoxPro files in the "File Types" section of the Options dialog of the Tools menu pad. In this section, Visual SourceSafe defines what files are to be automatically included in the add file dialog when working with a particular development platform. The default file types include all the standard Visual FoxPro file types, but is missing the .PRG file type. It will save you time if you add that in. This can be done in the SourceSafe Administrator; on the Tools menu, click Options, then click File Types, and add a semicolon, followed by an asterisk and .PRG in the file types list.

What files should be checked in?

All files in a project can be checked in. The following should be noted, however:

1. The project files (.PJX and .PJT) will need to be read/write before you will be able to modify the project, even when no records in the project itself will be changed. This is because of the way Visual FoxPro projects work. To accomplish this, you can either be sure to mark the Get dialog box appropriately each time you get files, or you can modify the SRCSAFE.INI, adding use_readonly = no. By default, the Get File dialog box does not appear each time you get a file. You need to set this in Tools/Options/Dialog, or press the SHIFT key when selecting the GET file. Setting the GET command options in Visual SourceSafe to do this automatically will be more productive.
   
   
2. During the course of the day, each developer will do local builds and test their modifications. No files should be checked in to the database until thoroughly tested. No file should be checked in unless its content is changed by the developer—not just changed by the build process. The person responsible for any add/delete activity should check out the files, make the requisite changes, then check them in. You may want to write a small utility to strip out, before checkin, the generated code from the .PJX/.PJT. The generated code adds nothing of value to the checked in files, but it does add dramatically to SourceSafe file size and checkin time. At the end of the day, one team member should be responsible for checking out the project files (including the .PJX and .PJT files), doing a BUILD ALL, and then checking the project files back in. This will keep the checked-in .PJX and .PJT files up-to-date each day.
   
   
3. Data files (.DBC, .DCT, .DCX, .DBF, .FPT, and .CDX) can be source code controlled when there is a testing data set. GET these files read/write (make modifiable). Data files containing source code in data-driven applications should always be checked in. Remember, any .DBC with triggers or Referential Integrity (RI) rules set will contain code and therefore need to be under source code control.
   
   
4. Configuration files (.FPW and .INI) can be source code controlled but should also be made modifiable upon GET.
   
   
5. Menu generation will create an .MPR file, this file must be read/write in order for the menu generation to succeed. As this file is created by the project manager from the "Source menu" files, the .MNX and the .MNT, you should not check this file in. However the .MNX and the .MNT should be checked in.
   
   
6. Because .APP, .EXE and .ERR files are generated by the "Source files," they should not be checked in. You only need to control the set of files necessary to create these files.

What can I do with a read-only file in the Visual FoxPro designers and editors?

The Visual FoxPro designers (Form, Class, Modi Comm Editor, and so forth) will allow you to view the source but not save any changes. In order to make and save changes the source files will need to be checked out. The class browser will not allow you to drag and drop a read only class onto the desktop in order to instantiate it, nor will it bring up read only classes in the class designer.

What files should I check out?

Many Visual FoxPro project components are made up of multiple files. Source code control operations should be performed on all files associated with the project component. For example, to add a form to SourceSafe, add both the .SCX and .SCT files. Then, whenever you check out the .SCX file, check out the .SCT file as well. This is not automatic, you must check out these files in "pairs" manually. You may want to set up batch files to GET, CHECKIN, and CHECKOUT these files. For example, if you want to check out the form MYSCREEN, use an (installation created) batch file that may be called SCRCKO.BAT (make sure you use the -GF- and -GWA options on the SS command in this file). The command may be something like SCRCKO MYSCREEN. This would check out both the MYSCREEN.SCX and MYSCREEN.SCT files and place them into the current directory. SCRCKIN.BAT could be created to check them in. If you do not do this, it is highly likely that a developer will forget to check out one or the other, then when checked in, the pairs will not match and you will be stuck with a non-buildable component.

Table 1. Visual FoxPro Component Files

Building an Application

A binary file must be checked out when it is compiled (nonbinary files, like .PRG files, compile into other files, and can be read-only when compiled). Therefore, if you select the Recompile All Files build option, all of the binary source files for the project must be checked out. In general, you will not want to select Recompile All Files.

Division of labor

Break into separate files or subprojects what will be separated in the division of labor. Because binary source files can only be checked out by one person at a time, multiple checkouts are not possible. This is because merging is not possible with binary files.

Acknowledgments

We acknowledge the help of Flash Creative Management, Inc., Hackensack, New Jersey, and Tom Fleming in providing portions of this material.