You can create complex applications quickly by combining the skills of a team of developers. However, team development requires some extra coordination to keep the development effort working smoothly. One strategy is to use source control software, such as Microsoft Visual SourceSafe™, to manage the files in a project.
This chapter provides strategies that you can follow to make team development successful. It assumes that you're already familiar with creating a Visual FoxPro application, as discussed in previous chapters of this book.
This chapter includes information on:
By working with a team of developers, you can create applications faster, and can develop more complex applications. You can blend the skills of different developers to create applications that would be difficult or impossible for a single developer to create.
However, team development requires extra effort in the development process. Successful team development depends on:
For example, imagine that your team is developing a complex application. Because the application is large, Visual FoxPro must allow several developers to be working at once on different components of the application. However, you want to be sure that only one developer at a time works on an individual element, such as a form, so that one developer doesn’t overwrite the changes made by another developer.
Furthermore, you want that developer to be able to code, test, and debug a form without affecting the other developers (and users) who continue working with an earlier version of the form. When the first developer is finished with the new form, the enhancements can then be integrated into the application.
You can follow the methods recommended in this chapter for coordinating the work of multiple developers. For example, this chapter provides information on how you can work with projects and class libraries in a multi-developer environment. For details, see Integrating Source Control with Visual FoxPro Projects and Developing Class Libraries in Teams later in this chapter.
Visual FoxPro provides a number of features that support team development. A significant feature of team development is the use of a source code control system to coordinate who can access and modify files in a project.
Source control is the generic term for tools that manage files in a multi-developer environment. Most source control tools work something like a traditional public library, maintaining a central repository of files — documents, programs, or any other files — in a location accessible to all developers. In addition, source control tools include the ability to track the changes that developers make to files and revert to earlier versions if necessary.
Generally speaking, source control tools provide some or all of these features:
Tip If your source control software supports comments, take advantage of it. Comments can greatly aid in the process of tracking changes and provide a useful history of application development.
To use source code control, users must join a source-controlled project (sometimes referred to as “enlisting” in a project). When users have joined a project, they can check out and check in the files that belong to that project.
Note You must enable your source control system’s option to check out the same file multiple times in order for several developers to work in a project concurrently. For details, refer to the documentation for your source code control software.
One of the most critical aspects of developing in teams is the ability to control who is allowed to change files. For example, if there are no controls on files, and if more than one developer is changing a program at the same time, there is a strong likelihood that one set of changes will end up being overwritten or discarded, wasting time and effort.
Visual FoxPro helps your team manage files in your projects by allowing you to integrate a source code control system into the Visual FoxPro Project Manager. By doing so, you can manage project files in a team development environment and ensure that development efforts proceed smoothly.
Visual FoxPro supports source code control tools by allowing you to integrate commercially-available source control software directly into your projects. You can use many of the version control systems currently available. (Contact the software vendor to find out if the software can be integrated with Microsoft development tools.) For example, if your development team already uses Microsoft Visual SourceSafe, you can specify that as the source control software to use with Visual FoxPro.
All source control in Visual FoxPro is managed through the Project Manager. When you set up a project in Visual FoxPro, you have the option to create a corresponding source code control project, which is referred to as “putting the project under source control.” After you’ve put a project under source control, Visual FoxPro helps you manage the files in the source-controlled project. When you want to modify a file — for example, if you edit a program or modify a form — Visual FoxPro prompts you to check out that file.
In Visual FoxPro, source control is used to manage files of all types, not just .prg files, but .scx, .frx, .lbx, .mnx, and .vcx files, and others as well. Although individual files can be shared between different Visual FoxPro projects, all source control operations are conducted on files within the context of a particular project.
Note Visual FoxPro doesn't prompt you to put data tables such as .dbf and .dbc files under source control when you create them, but you can add them manually to your source-controlled project.
When you work in the Project Manager with a project that's under source control, Visual FoxPro displays icons next to files that are under source control to indicate their status.
Project Manager showing source control icons
The following table summarizes the icons used in the Project Manager to indicate source control status.
| Icon | Meaning |
 |
The file is checked out to you. |
 |
The file is checked out to you and to one or more other developers. |
 |
The file is checked out to another developer. |
 |
The file is not checked out; you cannot change the file until you check it out. |
 |
The file has been merged. After examining the changes, you can check the file in. |
 |
The file has been merged and there are conflicts that need to be resolved. |
 |
Visual FoxPro cannot determine the source control status of the file. |
If a file isn't under source control, no icon appears next to it.
Note For details about merging files and merge conflicts, see Checking In Text Files later in this chapter.
To enable source control, first install your source control program according to the documentation provided with it. Typically, you install an administrator version on a server where the source code will be maintained, and then install the client version of the product on local machines.
Note All developers on a project must use the same source code control software.
After installing the source control software, you can set options so that Visual FoxPro will recognize it, and to specify defaults for your projects.
To enable source control in Visual FoxPro
Each time you start Visual FoxPro, it checks for a source control provider. If one is found, you can put or manage projects under source control.
To use source control software in Visual FoxPro, you put projects under source control, add files to your source-controlled projects, and update the project list for each project.
In Visual FoxPro, project information is maintained in a set of table and memo files with the extensions .pjx and .pjt. For example, if you've created a project called “MyProj,” the information about the project, including the list of files, their location, and whether they're compiled into the application file (.app or .exe file), is stored in the files called Myproj.pjx and Myproj.pjt.
When working in a team development environment, developers don't share the same project files (.pjx and .pjt files). Instead, developers maintain their own local copies of the .pjx and .pjt files.
To coordinate changes that individual developers make to a project under source control, Visual FoxPro maintains a project file list (or .pjm file, short for “project metafile”). The file containing the project file list is a text file that stores the same information as the .pjx and .pjt files, such as which files are currently included in the project.
The source code control software maintains a central project file list file stored with the other files in the central repository. In addition, each developer has a local copy of the project file list checked out that reflects his or her current version of the project.
Imagine you're working with a project, and that you're adding a new program (.prg file). When you add the new file (and assuming that you put this file under source control), Visual FoxPro updates your local copy of the project and shows the file when you use the Project Manager on your computer. Other developers aren't initially aware of your change, and their local copies of the project don't show the file you have added. Even though you haven't updated the project file list, you can still check in the new file for safekeeping and check it back out again as needed.
When you're finished with the new file — for example, when you've finished testing your new program — you can update the project file list. When you do, Visual FoxPro merges the information in your local project file list with that in the central project file list.
Visual FoxPro in turn updates your local project file list with changes it finds in the central project file list. If other developers have added files to the project, your local project file list is updated, local copies of the new files are placed on your computer, Visual FoxPro rebuilds your project (.pjx and .pjt files), and the Project Manager displays the added files for you to work with.
Managing project files using the project list
Note The project file list tracks only the project files that are explicitly under source control. If your project includes files that aren't under source control, they will not appear in the project file list, and Visual FoxPro will not add these files to other developers’ projects when they update their own project lists.
You must specify that a Visual FoxPro project will be source-controlled before you can take advantage of your source control software. You do this by adding a project to your source control system.
If source control software is enabled, you can specify that any new projects you create are automatically put under source control.
To create a new source-controlled project
After you've named the new project, Visual FoxPro will prompt you to create the new source-controlled project. The default name for the new project will be the same as the name of the Visual FoxPro project.
After you create the new source-controlled project, Visual FoxPro finishes creating the Visual FoxPro project. Before other developers can use the file, they must enlist in the project. For details, see Joining an Existing Source-Controlled Project later in this chapter.
If you're working with an existing project that isn't already under source control, you can create a new source-controlled project for it, and then put its files under source control.
To put an existing project under source control
Visual FoxPro displays the dialog box for your source control system that allows you to create a new project. By default, the name of the source-controlled project is the same as that of the Visual FoxPro project.
When you add an existing project to source control, Visual FoxPro prompts you to add the project’s files to the source-controlled project. For details, see Adding Files to a Source-Controlled Project in the next section.
After you put a Visual FoxPro project under source control, you can add individual files to the source-controlled project. If the Visual FoxPro project already contains files when you put it under source control, you can add them to the source-controlled project.
Note If the source control software supports it, Visual FoxPro allows you to keep the file checked out when you add it to the source-controlled project. If not, the file is checked in and you must check it out again in order to work with it. For details about checking files out and in after they're added to a project, see Managing Files in a Source-Controlled Project later in this chapter.
To add existing files to a controlled project
Note Keep checked out and Comment appear only if your source code control software supports these options.
Visual FoxPro generates the control files necessary for the source control software, and then adds the files to the project. If you've selected many files, this process can take some time.
You can set it up so that when you add a file to a project, Visual FoxPro will prompt you to put it under source control.
To specify that Visual FoxPro prompts you to put new file under source control
To make this setting the default, choose Set as Default, and then choose OK.
After you've added files to a project, you must update the project list before other developers can work with the new files. For details, see Updating the Project List later in this chapter.
If you are a new developer on a project that's already under source control, you must join the project before you can check files out and in. When you join a project, Visual FoxPro creates a local project list file and generates a current project file (.pjx file) for you.
To join an existing project
Tip All developers on a project must use the same directory structure for the files in a project, although the names of individual subdirectories can differ.
Even after files have been added to the source-controlled project, other developers will not be able to work with them. Developers will be able to manually use their source control system to check files out and in if they need to, but the added files will not be displayed in the Project Manager for any developer except the developer who added the files. To make the files available to other developers, update the project list.
When you update the project list, Visual FoxPro:
To update the project list
As part of the update procedures, Visual FoxPro prompts you to get the latest versions of files. If you have a file already checked out, as a general rule you shouldn't get the latest version, because your version is almost certainly more current than the one on the network.
If you're getting the latest version of a text file (such as a program), the source control software can attempt to merge the latest changes with your version. For more information about merging text files, see Checking In Files later in this chapter.
When you're finished, other developers should also then update their project list (using the same procedure) in order to be able to work with the files you’ve added.
If you no longer want to control the files in a project, you can detach the project from source control. When you do so, files remain in the source control project so that other developers can continue to use them and so you can examine their history or use them with other projects.
If you have project files on your computer that are tagged as read-only — that is, you have copies of files, but they're not checked out — you can remove their read-only attribute when the project is detached from source control.
Note When you detach a project from source control, you break the link between your local project files and the source-controlled project, and your local files become read-write. Be sure to institute manual version control procedures after detaching the project, or you run the risks inherent in working with files that are not under source control.
To detach a project from source control
You can remove individual files from source control if you no longer want them to be part of your source-controlled project. You might do this, for example, if a program or form becomes obsolete and is no longer part of your project
To remove a file from source control
If you remove a file from a Visual FoxPro project that's under source control, Visual FoxPro prompts you as usual whether you want only to remove the file from the project or to delete it from disk. A setting in the Options dialog box determines whether Visual FoxPro also prompts you to remove the file from the source-controlled project.
After a file has been removed from source code control, copies of it might still exist on other developers’ computers. If so, the file is treated as a local file only for those developers.
You can set up a file so that it's a member of two or more source-controlled projects at the same time. This is useful if you use common files, such as standard programs, libraries, or dialog boxes, in more than one project. When you share files between projects, changes you check in to a file are reflected in all the projects that share the file.
The specific method for sharing files between source-controlled projects depends on your source control software. If file sharing options aren't supported by your source control provider, file sharing commands will not be available on the menu.
The first step of the following procedure applies to all source control systems that support file sharing. The subsequent steps may differ, depending on your source control software.
To share files between controlled projects
The specific options available from this menu command depend on your source control system. For details, choose Help in the Share dialog box or refer to the documentation for your source control system.
Tip In Microsoft Visual SourceSafe, you can see what projects a file is a member of by using the Project Properties command and choosing the Links tab.
After you have put a Visual FoxPro project under source control, you can work with individual files or manage the project as a whole.
Some project components in Visual FoxPro actually consist of multiple files: a primary file and one or more implicit files. For example, when you create a form, Visual FoxPro creates an .scx file (the primary file) and an .sct file (the implicit file). The following components have multiple files:
| Component | Primary file type | Implicit file type(s) |
| Form | .scx | .sct |
| Report | .frx | .frt |
| Label | .lbx | .lbt |
| Class Library | .vcx | .vct |
| Menu | .mnx | .mnt |
| Table | .dbf | .fpt, .cdx, .idx |
| Database | .dbc | .dct, .dcx |
When a developer checks out a component file, such as a form, Visual FoxPro also manages the corresponding implicit file or files. Likewise, when a file is checked back in, or a new file added, Visual FoxPro manages the implicit file or files automatically.
Note If you generate and compile a menu, you create local .mpr and .mpx files as well. These aren't initially under source control, but you can add them as files to your project, and then put them under source control as you would other files.
When you're working in a source-controlled project, Visual FoxPro can prompt you to check files out when you modify them by opening the appropriate editor. For example, if you select a form and choose Modify to open the Form Designer, Visual FoxPro can first prompt you to check out the files for the form. (If you don't check out the files, the form is displayed in the Form Designer, but is read-only.)
However, you can also check out files manually, which is useful if you want exclusive access to the file, but don't want to open the editor for the file just at the moment. You might do this, for example, if you intended to work with a file offsite.
To specify that Visual FoxPro prompts you to check out files being modified
To make this setting the default, choose Set as Default, and then choose OK.
To check out a file manually
You must always check in files manually. Visual FoxPro doesn't automatically check in a file; for example, it doesn't check in a form when you close the Form Designer. Instead, it leaves the file checked out so you can continue to edit it, take it offsite, or work with it in some other fashion.
The exact result of the check-in process depends on the file you're checking in and on your source control software. For forms, menus, labels, class libraries, and other types of files, the file is treated as a binary file, and the source control software makes your new version of the file into the current one for other developers to check out.
Tip Always remember to check in files when you're done editing them. If you keep them checked out for long periods, you might prevent other developers from working with them, and you'll prevent the latest version of the file from being backed up during the course of your network backup.
To check in a file
When you check in a text file such as a .prg file, and if multiple versions of the file are checked out, the source control software doesn't simply overwrite the central version. Instead, it checks whether there have been changes to the file since you last checked it out. If so, it attempts to merge those changes with your file. To do so, it adds, deletes, and changes lines in your copy of the file.
When it's finished merging, the source control software might also give you the opportunity to check in your file. Don't check in your file right away. Instead, test your application using the new version of the file that incorporates both your changes and those of other developers. Only when you're satisfied that the application works correctly, check in your file. If other developers have made further changes to the same file, you might have to merge, test, and check in again.
In some instances, the source control software might report a merge conflict, which indicates that it cannot resolve changes between your changes and those of other developers. This can occur, for example, if you and another developer have been updating the same lines of the same program. If the source control software cannot merge successfully, it creates a version of the file that contains the original text plus your changes, marks the conflicts, and writes that file to your computer. (The exact means by which the conflicts are marked depends on the source control software you're using.) The file then appears in the Project Manager with a merge conflict icon:
To resolve the merge conflict, you must edit the file again, make your changes, and remove the merge conflict markers. When you're finished editing, Visual FoxPro prompts you to confirm that you've resolved all conflicts. The file is then marked with the merge icon:
Test your application to be sure that the changes are working properly. You can then attempt to check the file in again. If no more merge conflicts occur, your file becomes the current version.
If you've checked out a file, but decide to discard any changes you've made, you can undo the checkout. This has the effect of checking the file back in (that is, other users can then check the file out), but doesn't update it with changes. For example, if you mistakenly checked out a file instead of simply getting the latest version, undo the checkout instead of checking the file back in. This prevents the source code control system from having to create another version of the file, thus saving time and space.
Tip If you want to view a file but don’t need to check it out, you can get the latest version of it. For details, see Getting the Latest Version of Files in the next section.
To undo a checkout
If you want to view the latest version of a file, you can check it out. However, if the file is already checked out, or if you only want to view the file (not modify it), you can get the latest version of a file. When you do, Visual FoxPro copies the most current checked-in version of a file to your computer, but leaves it as a read-only file. You can get the latest version of a file even if it's currently checked out.
If the file you're getting is a text file, the source control software will merge the most current one with your version instead of simply overwriting it.
Note To merge files when getting the latest version, you might need to enable this as an option in your source control software. For details, see the documentation for your source control software.
To get the latest version of a file
Important If you already have the file checked out, Visual FoxPro prompts you to overwrite it. If you've made changes to the file since last checking it out, choose No when prompted to replace the file.
When working with files and with a project, you might need to compare the current local copy in your working directory with the current master copy in the source-controlled project. This can help you determine whether another user has changed a file, or it can help you pinpoint where you've made changes since you checked out the file.
Most source control systems can only compare and display differences between files if they're in text format. When Visual FoxPro compares forms, reports, menus, labels, and class libraries, it uses the text representations of those files. For details, see Checking for Differences in Forms, Reports, and Other Table Files in the next section.
Note If file comparison options aren't supported by your source control provider, they aren't available on the menu.
To see differences between projects
The resulting report is produced by your source control software, so the specific information provided can vary. In general, however, the source control system will display a window with two panes, and will highlight or otherwise mark the differences between the local and master copies of the file.
To see differences between files or the project list
The resulting report is produced by your source control software, so the specific information provided can vary. In general, however, the source control system will display the two versions side-by-side, and will highlight or otherwise mark new, deleted, and changed lines.
In Visual FoxPro, only a few types of files are treated as text files by the source control software. These include program source code (.prg) files and the project file list (.pjm file). Forms, reports, and other types of files are actually stored as tables of information about their components. For example, a form’s .scx file is a table of the controls in that form, plus information about the form itself. Table-type files are used to store information about forms (.scx files), reports (.frx files), menus (.mnx files), labels (.lbx files), and class libraries (.vcx files).
Because these files are stored as Visual FoxPro tables, source control systems cannot treat them as text files (the source control system treats them as “binary” files). As a result, tools for viewing differences between versions of these files cannot pinpoint the differences, nor can you see a history of changes.
In order to allow you to use source control to view differences in forms, reports, and similar files, Visual FoxPro creates text representations of them. Then, when you put one of these files under source control, Visual FoxPro creates a text version of the file, which it maintains automatically as you make changes.
Text representation of Visual FoxPro file
To support the capability to generate text representations of table-type files, Visual FoxPro includes the utility program Scctext.prg, or you can use a different program that you obtain from another source or write yourself.
To specify a text conversion utility
Visual FoxPro automatically calls the text conversion program whenever you add a form, report, menu, label, or visual class file to a source-controlled project. The utility generates a text file that has the same name as the primary file, but uses “A” as the last letter of the extension. For example, for a form called Myform.scx, the utility generates a text file called Myform.sca. When you check in the form (or other file) after changing it, the source control software automatically creates and checks in the text file.
If you specify a text conversion utility when you already have forms, reports, and similar files in your source-controlled project, you must temporarily remove them from the project, and then re-add them with text generation enabled.
To generate text representations for existing files in a project
As it puts the each file under source control, Visual FoxPro also creates the corresponding text representation for the file.
You can display information about individual files and about the project as a whole. For example, you can display the checkout history for an individual file or for the project list file. Information typically available includes:
To view checkout history for a file or the project list
The specific options available from this menu command depend on your source control system. For details, choose Help in the dialog box that's displayed or refer to the documentation for your source control system.
You can also view the information about an individual or about the project that's being maintained by the source control system. This usually includes information such as the checkout status of the file or project list, whether the file is a text or binary file (which determines if you can merge your changes with the centrally-stored file), and so on.
To view source control information for a file or the project list
The specific options available from this menu command depend on your source control system. For details, choose Help in the dialog box that's displayed or refer to the documentation for your source control system.
In addition to working together with projects and project files, your team must be able to share information in databases. Working with databases as a team involves not only the issues of ordinary concurrency control for data in tables, but the need to be able to share database control information as well.
For several developers to work with a database at the same time, they must be able to share the database (.dbc) file. In Visual FoxPro, the .dbc file can be shared between developers as an ordinary data table. The .dbc file must therefore be stored centrally with the tables making up the database. Developers shouldn't keep local copies of a .dbc file because changes that they make to the database will not be reflected in other developers’ versions of the file.
If you do need to change the .dbc file, note the following restrictions:
Views and connections work somewhat differently than tables. When you're first defining the view, Visual FoxPro uses the tables in a database, but doesn’t lock them. However, because the tables are in use, other developers cannot modify their structures.
From the time you first save a new view or connection definition, Visual FoxPro locks it exclusively until you close the View or Connection Designer. In other words, as long as you have the view or connection open in a designer, it's locked exclusively. While the view is locked, no one else can modify it.
When you use a view, its structure is cached locally. This ensures that if the view is modified while you're using it — for example, if you call REFRESH( ) or REQUERY( ) — your form or report continues to run correctly.
Because class libraries (.vcx files) are a crucial part of most Visual FoxPro applications, teams must be able to coordinate development efforts when creating them. Working with class libraries in a team involves many of the same coordination issues that any set of application components does, but adds some issues unique to classes:
As with complex forms and programs, it's good practice to isolate development in a class library, so that one developer can make changes to the library without affecting the work of other developers. Ideally, the team of developers can work with a class library while it's being enhanced by another developer, without having to worry about whether changes to the libraries will cause problems in the application.
When a class is used, Visual FoxPro caches it on the user’s computer, even after a form that uses the class has been released. You must explicitly release the class before Visual FoxPro will recognize it as no longer in use. If you've used a class during the current session (and it's therefore cached), but want to load a new version of the class, be sure to release the class to force Visual FoxPro to reload it from the changed library.
When you put a class library under source control, only one developer can check the library out at a time. The library becomes read-only for other developers. As a rule, this doesn't interfere with application development, because developers can use and subclass a library even if it's read-only. While the application developers work with the read-only version of the library, the class library developer can modify all the classes in the library.
If you use this approach, the developer who is updating the library shouldn't check in the file until it has been finished and tested. Otherwise, other developers will get the incomplete version of the file when they update their project file lists or get the latest versions of files.
If the library is very complex, you can also consider breaking it into smaller libraries for development. Another advantage of this approach is that smaller library files load faster. However, this means that different classes might be finished and available at different times.
Because each approach has its advantages, you should examine the requirements of your development team and choose the strategy that best fits how you work.