Chapter 29 -- Developing in Teams | Microsoft Visual FoxPro 6. 0 Programmer's Guide 1998

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:

Understanding Team Development
Working with Source Control Software in Visual FoxPro
Managing Visual FoxPro Projects under Source Control
Managing Files in a Source-Controlled Project
Developing and Modifying Databases in Teams
Developing Class Libraries in Teams

Understanding Team Development

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:

Allowing several developers to work with the same projects and databases at the same time.
Coordinating the changes that are made to the same programs, forms, or other application elements, so that one developer s changes don t overwrite those of another developer.
Allowing developers to enhance existing application elements (for example, programs or class libraries) without affecting the work of other developers who are currently using these elements.

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.

Understanding Source Control

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:

Check out, check in Developers check out a file by downloading a copy from the central repository to their local computer before modifying it. As a rule, while a file is checked out, other developers cannot check it out or modify it, but they can usually view it by synchronizing, or getting a read-only copy of it. (If the file is a text file, such as program source code, it's possible for several developers to check out the same file, and then merge others changes with their local copy.) When developers are done with a file, they can check in their changes by checking in, or uploading, their local copy to the central repository. As part of the file check-in process, most source control tools prompt the developer to enter any comments about changes made to the file.
Merging To allow several developers to work concurrently on the same file, source control software allows multiple developers to check out the file at the same time. (This can usually be done only with text files such as program source code.) If another developer has changed the file, the source control system can integrate those changes into your version of the file.
Project control Developers can organize files into projects or other work-specific categories. Files can often be shared between projects if necessary.
Change tracking Most source control systems keep track of the changes made in a file when it's checked in. This allows developers to reconstruct earlier versions of the file, which is useful for recovering earlier work.
Difference checking Source control software allows developers to compare versions of a file and review the differences between them.
History Developers can examine the check-in history for each file, including the comments made by each developer when checking in the file.
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.

Working with Source Control Software in Visual FoxPro

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.

Integrating Source Control with Visual FoxPro Projects

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.

Enabling Source Control

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

From the Tools menu, choose Options.
In the Options dialog box, choose the Projects tab.
In the Source control options area, select the name of your source control program in the Active source control provider list.
To have Visual FoxPro prompt you to add new projects to source control, select Automatically add new projects to source control.

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.

Managing Visual FoxPro 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.

Working with the Project File and Project List File

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.

Putting Projects Under Source Control

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

In the Options dialog box, choose the Projects tab, and then select a source code control provider if you haven't already done so.
Make sure Automatically add new projects to source control is selected, and then choose OK. To make this setting the default, choose Set as Default, and then choose OK.
From the File menu, choose New, and then start a new Visual FoxPro 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

Open your Visual FoxPro project in the Project Manager.
From the Project menu, choose Add Project to 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.
Create the source-controlled project as you normally do with your source control software.

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.

Adding Files to a Source-Controlled Project

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

From the Project menu, choose Source Control and then choose Add Files to Source Control.
In the Add Files to Source Control dialog box, select the files you want to add.

Note Keep checked out and Comment appear only if your source code control software supports these options.
Choose OK.
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

In the Projects tab of the Options dialog box, make sure Automatically add new projects to source control is selected, and then choose OK.
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.

Joining an Existing Source-Controlled Project

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

From the File menu, choose Join Source Control Project.
In the Open Project dialog box, select the server and directory that contains the Visual FoxPro project file you want to join.
Set the working directory on your local machine; this specifies where the source control system will place files when you check them out and where it will look when you check them back in. For example, if you're using Visual SourceSafe as your source control provider, choose Browse from the Directory area and select an existing directory, or type the name of a new directory.
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.

Updating the Project List

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:

Generates a new local project file list (.pjm file).
Checks in the new project file list (with the option set to keep the file checked out).
Merges the local and central project file lists if there are differences. If a merge conflict occurs, Visual FoxPro displays a dialog box to help you resolve the merge conflicts.
Rebuilds the local project (.pjx) file based on the merged project file list.
Gets local copies of files added to the project by other developers.
Prompts you to get the latest versions of the project files.
Refreshes the display in the Project Manager to reflect changes.

To update the project list

From the Project menu, choose Source Control, and then choose Update 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.

Detaching a Project from Source Control

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

Check in all the files under source control.
From the Project menu, choose Detach Project from Source Control.

Removing Files from a Source-Controlled Project

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

In the Project Manager, select the file to remove.
From the Project menu, choose Source Control, and then choose Remove Files from Source Control.
In the Remove Files from Source Control dialog box, select the files to remove, and then click OK.

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.

If Remove files from source control upon removal from project is checked, Visual FoxPro also prompts you to remove the file from the source-controlled project.
If Remove files from source control upon removal from project isn't checked, you're not prompted, and the file is left under source control.

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.

Sharing Files Between Source-Controlled Projects

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

From the Project menu, choose Source Control and then choose Share Files.
In the dialog box that appears, indicate what files you want to share with your current project, and what project they currently belong to.
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.

Managing Files in a Source-Controlled Project

After you have put a Visual FoxPro project under source control, you can work with individual files or manage the project as a whole.

Working with Multi-File Components

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.

Checking Out 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

In the Projects tab of the Options dialog box, make sure the option Check out files upon modify is checked, then choose OK.
To make this setting the default, choose Set as Default, and then choose OK.

To check out a file manually

In the Project Manager, select the file to work with.
From the Project menu, choose Source Control, and then choose Check Out.
In the Check Out Files dialog box, select the file or files you want to work with, and then click OK.

Checking In Files

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

In the Project Manager, select the file to work with.
From the Project menu, choose Source Control, and then choose Check In.
Enter a comment describing the changes you've made.
In the Check In Files dialog box, select the file, and then click OK.

Checking In Text Files

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.

Discarding Changes

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

In the Project Manager, select the file to work with.
From the Project menu, choose Source Control, and then choose Undo Check Out.
In the Undo Check Out of Files dialog box, make sure the file you want is selected, and then click OK.

Getting the Latest Versions of Files

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

In the Project Manager, select the file for which you want the latest version.
From the Project menu, choose Source Control, and then choose Get Latest Version. If the file is currently checked out, you're prompted to replace or merge your checked-out version with the current version from the source control project.
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.

Comparing Files or Projects

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

From the Project menu, choose Source Control, and then choose Show Project Differences.
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

If you're viewing differences for a single file, in the Project Manager, select the file for which you want to see differences.
For a single file, from the Project menu, choose Source Control, and then choose Show Differences. For the project list, from the Project menu, choose Source Control, and then choose Show Project List Differences.
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.

Checking for Differences in Forms, Reports, and Other Table Files

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

In the Options dialog box, choose the Projects file.
In the Text generation box, enter the name of the conversion program.
Choose Set as Default, and then choose OK

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

Back up all the files that will be affected: forms, reports, menus, labels, and class libraries.
Verify that the files aren't already checked out.
From the Project menu, choose Source Control, and then choose Remove Files from Source Control.
Select the files to remove from the project, and then choose OK.
Enable text generation, following the steps described earlier.
From the Project menu, choose Source Control, and then choose Add Files to Source Control.
Select the files to add, and then choose OK.

As it puts the each file under source control, Visual FoxPro also creates the corresponding text representation for the file.

Displaying File and Project Information

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:

The version number, which indicates how many times a new version of the file or project list has been checked in.
Who checked in the file or project file each time.
The date and time it was checked in.
What comments the developer added when checking in the file or project list.

To view checkout history for a file or the project list

If you're viewing the history of a single file, in the Project Manager, select the file for which you want to see the history.
For an individual file, from the Project menu, choose Source Control, then choose Show History. For the project list, from the Project menu, choose Source Control, and then choose Show Project List History.
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

If you're viewing the history of a single file, in the Project Manager, select the file for which you want to see the history.
For an individual file, from the Project menu, choose Source Control, and then choose Source Control Properties. For the project list, from the Project menu, choose Source Control, and then choose Project Properties.
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.

Developing and Modifying Databases in Teams

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:

Developers cannot modify the same database element (such as a table structure, view, or connection) at the same time. When a developer modifies a database element, Visual FoxPro locks its entry in the .dbc file; other users can read the entry (that is, they can issue a USE command), but they cannot modify it (MODIFY STRUCTURE).
If a database element is in use, you cannot modify its structure. For example, if one developer has a table open, no other developer can modify its structure.
If you call the DBSETPROP( ) function to change the properties of a database, the function puts a write lock on the object being updated. If there's a lock conflict, DBSETPROP( ) follows the rules established with SET REPROCESS.

Working with Views and Connections

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.

Developing Class Libraries in Teams

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:

Changes to classes are propagated not just to applications that use those classes, but to all subclasses derived from them.
Multiple classes are often stored in a single library file, the minimum unit that can be managed by a source control system.

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.

Putting Class Libraries Under Source Control

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.