Previous Page TOC Next Page

- 24 -
Managing Large Projects with Visual SourceSafe 4.0


Visual Basic rapidly is gaining acceptance as an enterprise-scale development tool for client/server database front-ends. The major obstacle in the road to adoption of Visual Basic as an organization-wide standard has been Visual Basic's limitation to running in the Windows environment. Traditionally, large organizations have insisted upon use of cross-platform development tools that can create applications for use under Windows, Macintosh, and UNIX operating systems. As Windows on Intel-architecture (Wintel) PCs has continued to gain market share, the importance of cross-platform capability has declined dramatically. The cost of supporting a small minority of fervid Mac fans or hard-core UNIX devotees within a organization having 80 percent or more "Wintel" users is difficult or impossible to justify in an age of downsized budgets and concomitant demands for increased productivity of information systems and PC support personnel.

Enterprise-scale development tools require team programming capabilities. The archetypical Visual Basic developer is a single programmer, either an employee or a consultant, creating a relatively simple database front-end, often in response to an ad hoc request by a business unit manager. One of the most remarkable characteristics of Visual Basic is how fast you can create a workable prototype of a specialized decision-support application that queries an existing database. Prototypes often are created from a specification based on a combination of arm-waving and form designs drawn on cocktail napkins. In many cases, tweaking the prototype in response to early adopter requests results in a de facto production application that becomes very popular with its users. The "owner" of the application cites its low cost and popularity when confronted with issues such as inefficient use of server connections, queries that consume extraordinary amounts of server and network resources, lack of documentation, and other sins of commission or omission.

A structured approach to database front-end development is mandatory when the scope of the project exceeds that which can be managed by a single programmer or if the project involves vital corporate activities, such as booking orders, issuing invoices, or forecasting manufacturing requirements. Such applications, often called "mission-critical" (a clich&éacute;), typically are created by teams of programmers working to a detailed specification and delivery timetable. Team programming requires a means of organizing, archiving, and controlling access to source code components extending through the development process into the maintenance phase of the application life cycle. Applications that aid in automating these activities are called version control systems. Mainframe COBOL programmers are steeped in version control methodology; use of formalized version control procedures is much less common among Visual Basic programmers. Even sole practitioners of Visual Basic programming who write relatively simple database applications for small-business clients, however, can benefit greatly from the discipline (and backup procedures) imposed by version control systems.

This chapter discusses the use of Visual SourceSafe 4.0, a component of the Enterprise Edition of Visual Basic 4.0, as the version control system for both large- and small-scale database front-end development. There are several third-party version control products that are capable of accommodating Visual Basic projects. The primary advantage of SourceSafe, aside from being a Microsoft product bundled with Visual Basic or for sale as a shrink-wrapped product, is the integration of SourceSafe with the Visual Basic 4.0 development environment. Although SourceSafe can operate in single-user mode on one PC, SourceSafe primarily is designed for networked file sharing and archiving. The examples of this chapter are based on a Windows 95 client for development and testing of 32-bit Visual Basic project files stored in a shared SourceSafe folder on Windows NT 3.51 Server.

Understanding Visual SourceSafe Methodology


Like most other version control systems, SourceSafe supplies the following four basic services:

SourceSafe uses project database files to store the current version of all files that comprise one or more Visual Basic projects. Prior versions of a project are stored in the form of changes from the current version (often called delta files). You don't work directly with the SourceSafe project files; you must move the files out of the SourceSafe project file (called "checking out a file") in order to open the files with Visual Basic 4.0. Depending on your project and file permissions, the checked out files may have read-only or read-write attributes.


SourceSafe isn't limited to handling Visual Basic 4.0 and Visual C++ source code; you also can use SourceSafe to manage Visual Basic 3.0 projects and text files. As an example of text file version control, Microsoft uses SourceSafe 4.0 to manage changes to the tens of thousands of Web pages that comprise the Microsoft Web site.

Installing and Setting Up Visual SourceSafe


The Enterprise Edition provides a separate Setup program for SourceSafe, which is similar to the Setup programs that install the 16-bit and 32-bit versions of Visual Basic 4.0. You must perform two installations to make SourceSafe operable with Visual Basic 4.0. In a networked environment, you first install the SourceSafe server components on the server by following these steps:

  1. Create a server share to contain the SourceSafe database, help files, integration macros, and conversion utilities. The default name for the server share is \\ServerName\VSS. All users of SourceSafe must have full read-write permissions for this share.

  2. Start the SourceSafe Setup application, type your name and organization, then type the CD-ROM key to open the first Setup dialog, which proposes C:\VSS as the default folder for the SourceSafe files. (See Figure 24.1.)

    Figure 24.1. The SourceSafe Setup dialog that follows dialogs for entering user information and the CD-ROM key.

  3. Click the Change Folder button to display the Change Folder dialog, and then click the Network button to display the Map Network Drive dialog.

  4. Map the server share to a logical drive letter (see Figure 24.2); then click OK to close the Map Network Drive dialog and click OK again to close the Change Folder dialog and display the second Setup dialog. (See Figure 24.3.)

    Figure 24.2. Mapping the server share to a local logical drive letter for the SourceSafe database installation.

    Figure 24.3. The Setup dialog that lets you choose the type of SourceSafe installation.

  5. Click the Server button to initiate a standard networked installation of SourceSafe. In the Choose Program Group dialog, select the Start Menu program group for SourceSafe. (The default is Microsoft Visual SourceSafe; if you use SourceSafe only with Visual Basic, you might want to install SourceSafe in the Visual Basic 4.0 program group.)

  6. Click OK to perform the installation on the server. The Setup program installs DOS, Win16, and Win32 versions of SourceSafe on the server.

  7. When server installation is complete, a message box advises that server setup was successful. Click OK to terminate the setup program.


If you want to install a non-networked system with the SourceSafe database on the same PC as the SourceSafe client, click the Custom button instead of the Server button in preceding step 5. Follow the instructions to install both the client and server files on the same computer. One of the advantages of using the Custom installation is that you need not install all three versions of SourceSafe. As an example, if you are only running Windows 95 and Windows NT, you can forego installation of the DOS and Win16 versions of SourceSafe.

To integrate the SourceSafe database with Visual Basic 4.0 (or Visual C++), you must install the SourceSafe client application either from the Enterprise Edition CD-ROM or, preferably, from the networked client installation feature created in the Netsetup folder during the server setup process.


You must install Visual Basic 4.0 before you install the SourceSafe client in order to integrate SourceSafe with the Visual Basic development environment.

Follow these steps to install the SourceSafe client from the server share:

  1. Choose Start | Run and click the Browse button of the Run dialog to open the Browse dialog.

  2. Look in the server share, select Netsetup.exe (see Figure 24.4), and click the Open button to close the Browse dialog. Click OK in the Run dialog to execute Netsetup.exe and open the initial client Setup dialog (see Figure 24.5). Click continue to proceed with the client installation.

    Figure 24.4. Locating Netsetup.exe in the SourceSafe server folder.

    Figure 24.5. The initial Setup dialog for installing the SourceSafe client from the server share.

  3. Accept or alter the Name and Organization data for the client to display the client folder Setup dialog. The default folder is C:\VSS. (If you want to change the location of the SourceSafe client, click the Change Folder button and enter the drive and folder name.) Click OK to display the Network Client Setup dialog. (See Figure 24.6.)

    Figure 24.6. The Network Client dialog for installing a local copy of the SourceSafe client.

  4. Click the large, square button to proceed with the SourceSafe client installation.

  5. Select the program group for the SourceSafe client in the Choose Program dialog and click the Continue button. Netsetup.exe installs the DOS, Win16, and Win32 clients in individual subfolders of the local SourceSafe folder and then displays a message box indicating successful completion.

  6. Click OK to close the SourceSafe client Setup application. The SourceSafe executable applications appear in the program group you specified in the preceding step. (See Figure 24.7.)

Figure 24.7. SourceSafe applications installed in the SourceSafe program group.

Administering Visual SourceSafe


When you first install SourceSafe, default Admin and Guest accounts are created, both with read-write privileges. Neither of these default accounts have passwords assigned; therefore, anyone with access to the server share for the SourceSafe database can launch and use SourceSafe. Unless you're the only user of the network, you should implement the SourceSafe security system before adding existing or creating new Visual Basic projects with SourceSafe version control. The following sections describe how to implement security using the SourceSafe Administrator application.

Securing the Admin Account


Follow these steps to secure the Admin account by adding a password:

  1. Select Start | Programs | Microsoft Visual SourceSafe | Visual SourceSafe 4.0 Admin - 32-bit menu to open the Visual SourceSafe Login dialog. (See Figure 24.8.)

    Figure 24.8. The Visual SourceSafe Administrator application's Login dialog.

  2. The Login dialog defaults to the Admin user with an empty password. Click OK to open the Visual SourceSafe Administrator window.

  3. Select the Admin user entry, if it is not selected, and choose Users | Change Password to open the Change Password dialog.

  4. Type the Admin user's password in the New Password text box and confirm the password in the Verify text box (see Figure 24.9). Click OK to close the Change Password dialog.

    Figure 24.9. Changing the password for the Admin user in the Visual SourceSafe Administrator application.

  5. Click OK in the message box that confirms the password change.

  6. Close the Administrator application and login as Admin with the new password to verify that the Admin account is secure.

The preceding procedure for changing passwords applies to changing the password for any user.

If you forget the password for the Admin account, you cannot open the SourceSafe Administrator application to change the password. Make sure to store a copy of the current Admin password in a safe place that is accessible to your organization's upper management in the case of your incapacitation.

Modifying the Guest Account Privileges


If you choose to retain the Guest account without password protection, you should alter the account's privileges to provide for read-only access to SourceSafe project files. To edit a user account, follow these steps:

  1. Launch the Visual SourceSafe Administrator application if it is not running.

  2. Select the Guest account entry and choose Users | Edit User or double-click the Guest account entry to open the Edit User dialog.

  3. Mark the Read-Only checkbox and click OK to close the Edit User dialog. (See Figure 24.10.)

Figure 24.10. Removing Write permission from the Guest account.

  1. The Rights entry for the Guest user changes from Read-Write to Read-Only.

You use the Edit User dialog to change the name and basic permissions of any SourceSafe account.


Visual SourceSafe uses the term rights to denote user permissions. For consistency with database terminology, this book uses permissions instead of rights.

Adding a New Visual SourceSafe User


To add a new user account, follow these steps:

  1. Launch the Visual SourceSafe Administrator application if it's not open.

  2. Choose Users | Add User to open the Add User dialog.

  3. Type the user name and password in the text boxes (see Figure 24.11). If you want to bypass the login procedure, type the new user's network logon ID and network password in the text boxes.

    Figure 24.11. Adding a new SourceSafe user with read-write permissions.

  4. Mark the Read-Only checkbox, if necessary, and click OK to close the Edit User dialog.

  5. The new user is added to the User list.


The Use network name for automatic user log in checkbox of the SourceSafe Options property page must be marked for a user to bypass the SourceSafe Login dialog. Automatic login is convenient for users, but the SourceSafe Admin must manually change the password each time the user changes his or her network logon password.

Setting Up Default User Project Permissions


By default, project security is disabled and the default Read-Write or Read-Only permissions granted to users control the access to individual projects. In multi-developer environments, you're likely to want to assign different individual users an individual set of permissions for specific projects. Table 24.1 lists the four levels of permissions for SourceSafe projects. Like permissions for Jet database files, higher-level permissions inherit lower-level permissions; thus, the Add permission includes Check Out and Read permissions. As would be expected, users assigned Read-Only rights have only Read (R) permissions.

Table 24.1. Visual SourceSafe project permissions.

Permission Description
Read (R) Allows viewing but not altering of project files (enables View and Get commands)
Check Out Allows viewing and modifying of project files (enables Check Out, Check In, and Undo Check Out commands)
Add Allows viewing, modifying, and changing of the file source file complement of a project (enables Add, Delete, and Rename file commands)
Destroy Allows destructive commands that purge files from the SourceSafe database (enables Destroy, Purge, and Rollback commands)

To initiate project-level security, follow these steps:

  1. With the Visual SourceSafe Administrator application open, choose Tools | Options to open the Options properties sheet.

  2. Click the Project Security tab to display the properties page for setting up project security.

  3. Mark the Enable project security checkbox. By default, new users automatically are granted all permissions.

  4. At the minimum, clear the Destroy checkbox (see Figure 24.12). Under no conditions should new users automatically be granted Destroy permission.

    Figure 24.12. Setting default project-level Permissions for new users in the Project Security properties page.

  5. Click OK to close the properties sheet.

When you enable project-level security, the Rights by Project, Rights Assignment for User, and Copy User Rights choices are added to the Visual Source Safe Administrator's Tools menu. (See Figure 24.13.)

Figure 24.13. Choices added to the Tools menu after implementing project-level security.

Verifying and Setting Individual User Permissions


The Admin and Guest default accounts, as well as any other users you add prior to establishing project-level security, inherit permissions based on the original Read-Write or Read-Only rights assigned when creating the user account. Typically, programmers might be assigned Check Out permission, project leaders assigned Add permission, and project managers assigned Destroy permission.


Note: You cannot alter permissions for the Admin account nor can you add default permissions for users with Read-Only rights, because such users are restricted to Read (R) permission only.

To verify or alter default permissions for a user, follow these steps:

  1. In the Visual SourceSafe Administrator window, select the user account whose default permissions you want to change.

  2. Choose Tools | Rights Assignment for User to open the Assignments for UserName dialog. Default rights apply at the root level ($/) of the SourceSafe database and extend to project subfolders. If you are only verifying permissions, click Close to close the Assignments dialog.

  3. Clear the checkbox in the User rights frame that corresponds to the level of security higher than that to be assigned to the user. (See Figure 24.14.)

    Figure 24.14. Removing Add/Delete/Rename rights from the Programmer user.

  4. Click Close to assign the modified permissions and close the Assignments dialog.


You can assign or remove specific user permissions for individual projects by clicking the Add Assignment or Delete Assignment buttons to display the corresponding dialog. At this point in the chapter, no projects have been added to the SourceSafe Database, so individual project permissions are not applicable.

Setting Up Visual SourceSafe for Use with Visual Basic 4.0


When you install the SourceSafe client, a registry key automatically is added to specify Visual SourceSafe 4.0 as a Visual Basic source code control add-in. The SourceSafe client adds a SourceSafe choice to Visual Basic 4.0's Add-Ins menu with the following four submenu choices:

Figure 24.15 shows the choices SourceSafe adds to the Tools menu. The sections that follow describe the use of the SourceSafe submenu commands in the preceding list.

Figure 24.15. SourceSafe client choices added to Visual Basic 4.0's Tools menu.

Placing a Project Under SourceSafe Control


Most SourceSafe users are likely to create at least the core of a Visual Basic project and then place the project under SourceSafe version control. You can give SourceSafe a "test drive" with one of the sample applications, such as VisData, supplied with Visual Basic 4.0. Using a sample application to gain experience with SourceSafe is a safer approach than experimenting with a production application in which you've invested many hours of programming time.


Before you can place a project under SourceSafe control, you must first save the project.

Follow these steps to place the VisData sample data under SourceSafe source code control:

  1. After installing SourceSafe, open Visdata.vbp from your \VB4\Samples\Visdata folder. Upon opening VisData, you receive the message shown in Figure 24.16 (if the "dirty" flag is set) or a simpler message, "Do you want to place this project under source code control?" If you receive the message shown in Figure 24.16, click OK, save the project, and then choose Add-Ins | SourceSafe | Add Project to SourceSafe. If you receive the shorter message, click Yes to open the Add SourceSafe Project dialog. (See Figure 24.17.)

    Figure 24.16. The message box that prompts you to save your project before adding it to the SourceSafe database.

    Figure 24.17. The initial state of the Add SourceSafe Project dialog.

  2. The entry in the Project text box is derived from the project filename. Alter the project name, if you want, and click Create to add the project to the SourceSafe database. (See Figure 24.18.)

    Figure 24.18. Specifying the SourceSafe project name.

  3. Click OK to open the Add to SourceSafe dialog. Click Select All to make sure all of the files are added to the database; then enter a description of the project in the Comment text box (see Figure 24.19). Click OK and the Source Code Control Results dialog displays the progress of the addition of the source code files to the database. (See Figure 24.20.)

    Figure 24.19. Specifying the files to be copied to the SourceSafe database and adding a descriptive comment to the project.

    Figure 24.20. The progress indicator that appears during copying of the source files to the SourceSafe database.

  4. When the addition of files to the SourceSafe database is complete, the Source Code Control Results dialog's Cancel button changes to Close. Click Close to close the dialog, if necessary. The icons representing files in the Project window change to indicate that the files now are under SourceSafe source code control (see Figure 24.21) and the local copies are read-only. (The small icon under the form symbol is a padlock, indicating read-only status.)

Figure 24.21. The Project window displaying project files under SourceSafe source code control.

At this point, you have identical copies of all of the project files in their original location on your computer and in the $/Visdata "folder" of the SourceSafe database. With a project under SourceSafe control, the Add-Ins | SourceSafe menu appears, as shown in Figure 24.22. The following new menu items are added when your project is under SourceSafe control:

Figure 24.22. The SourceSafe menu with an open project under SourceSafe control.


Note: Project files added to the SourceSafe database are read-only until you check out the files from SourceSafe.

Setting Source Code Control Options


Choosing Add-Ins | SourceSafe | Options opens the Source Code Control Options dialog, shown with default values in Figure 24.23, in which you set default options for the operation of SourceSafe with checked-out files. Each of the drop-down lists provides, Ask, Yes, and No options for the following questions:

Figure 24.23. The Source Code Control Options dialog for determining the behavior of SourceSafe with checked out files.


Note: The default selection for the Remove files. . . option is Ask. For symmetry with the Add files. . . option, you should set the Remove files. . . option to the same value as that for the Add files. . . option.

Clicking the Advanced button of the Source Code Control Options dialog opens the SourceSafe Options properties sheet. The following sections describe the options you can set in the three pages of this property sheet.

General Properties Page

The General Page of the SourceSafe Options properties sheet appears in Figure 24.24. The General Page lets you set the following properties:

Figure 24.24. The General page of the SourceSafe Options properties sheet.

Local Files Properties Page

The Local Files page of the SourceSafe Options properties sheet, shown in Figure 24.25, provides the following options:

Figure 24.25. The Local Files page of the SourceSafe Options properties sheet.

Integration Properties Page

The Integration page of the SourceSafe Options properties sheet, shown in Figure 24.26, primarily supplies read-only information about the SourceSafe paths and databases. The Integration page lets you set the following two options:

Figure 24.26. The Integration page of the SourceSafe Options properties sheet.

Using Visual SourceSafe with Visual Basic 4.0


The preceding sections of this chapter deal primarily with the features of Visual Source as a standalone version control application. The sections that follow describe how to use the Visual SourceSafe 4.0 add-in to Visual Basic 4.0 to automate version control of your Visual Basic projects.

Checking Out a Project with the SourceSafe Explorer


The recommended method of checking out a project from SourceSafe when you have the project files on your local disk drive is to use the SourceSafe Explorer. To use SourceSafe Explorer to check out a Visual Basic 4.0 project, follow these steps:

  1. Save and check in your current project, if applicable.

  2. Choose Add-Ins | SourceSafe | Run SourceSafe to open the SourceSafe Explorer. (Log in to SourceSafe if you haven't configured automatic login).

  3. Select the project you want to check out. Selecting a project displays a list of its files in the right-hand pane. Figure 24.27 shows the SourceSafe Explorer window with three sample projects; the Visdata project is selected.

    Figure 24.27. The SourceSafe Explorer with the Visdata project selected.

  4. Choose SourceSafe | Check Out or click the Check Out Files/Project button.

  5. If you haven't assigned a working folder for the project's files (No Working Directory appears above the file list pane), the message box shown in Figure 24.28 appears. Click OK to display the Set Working Directory dialog, shown in Figure 24.29.

    Figure 24.28. The message that appears when you haven't specified a local working folder for a SourceSafe project.

    Figure 24.29. Specifying a local working folder in the Set Working Directory dialog.

  6. Select the drive and folder that holds the local files for the project and then click OK to display the Check Out ProjectName dialog. (You can create a new folder for local project files by clicking Create.)

  7. Click the Advanced button to display all of the Check Out ProjectName dialog. Enter a comment to appear to others who check out Visdata, if you want, as shown in Figure 24.30.

    Figure 24.30. Adding a check out comment in the full version of the Check Out ProjectName dialog.

  8. Click OK to close the Check Out ProjectName dialog and check out the project to your local project folder. When the check out process is complete, checkmarks appear in the icons for the files in the right-hand pane, as shown in Figure 24.31.

    Figure 24.31. The appearance of the SourceSafe Explorer window after checking out a project.

  9. From Visual Basic's File menu, use the Open command to open the project from the local project folder. When the message box shown in Figure 24.32 appears, click OK. The Source Code Results dialog appears, and a second message box, shown in Figure 24.33, requests confirmation for overwriting the existing files; click Yes All to update the local files.

    Figure 24.32. The message box that requests confirmation that you want to use the last-checked-in version of the SourceSafe project files.

    Figure 24.33. The message box that requests confirmation that you want to overwrite your local project files with the SourceSafe project files.

  10. When the process of replacing your project files is complete, SourceSafe's Source Code Control Results dialog and Visual Basic's Project window appear, as shown in Figure 24.34. The icons for each file include a miniature checkmark, indicating the files are checked out. Click the Close button of the Source Code Results dialog to work on your checked out project.

Figure 24.34. The appearance of the SourceSafe Explorer dialog after checking out a project.


The cascading message boxes requesting confirmation of file overwriting operations can be minimized by changing the applicable source code control options described in the preceding sections from Ask to Yes.

Using the Open New SourceSafe Project Menu Choice


Although the User's Guide for SourceSafe recommends using Visual SourceSafe to check out project files, you can use Visual Basic's Add-Ins | SourceSafe | Open New SourceSafe Project menu choice to check out a project under SourceSafe control. Using this menu choice displays the Open SourceSafe Project dialog, as illustrated in Figure 24.35. Click OK to begin the process. When the confirmation message box of preceding Figure 24.33 appears, click OK. The result of using the Open New SourceSafe Project command is the same as that of the SourceSafe Explorer's check out process.

Figure 24.35. The Open SourceSafe Project dialog for checking out a SourceSafe project.

Placing Database Files Under SourceSafe Control


When working on a database application, you can place local or shared database file(s) under SourceSafe control by adding the database file(s) to the project with the SourceSafe Explorer. The following sections discuss placing local and server-shared database files under SourceSafe control.


Placing large databases under SourceSafe control can slow down check out and check in processes dramatically. Each time you change the content of the database, SourceSafe interprets the change as a new version. Consider placing a copy of the database under SourceSafe as a separate project and use SourceSafe only to backup the database, rather than to perform version control functions.

Adding Local Database Files to the SourceSafe

A local Jet .mdb database often is used in conjunction with shared file or client/server databases to hold initialization data, user preferences, and temporary TableDef and/or QueryDef objects.

If the database file(s) are located in the same folder as your other project files, you can use the SourceSafe Explorer to add the database file(s) by following these steps:

  1. In SourceSafe Explorer, choose File | Add File to open the Add File to $/ProjectName dialog. (See Figure 24.36.)

    Figure 24.36. The Add File to $/ProjectName dialog for placing local database file(s) under SourceSafe control.

  2. 2. From the file list, select the database file to add; then click the Add button.

  3. 3. When you've added all of the required database files, click the OK button to open the Add File FileName dialog.

  4. 4. Add a descriptive comment, check the Store only latest version checkbox (to minimize storage space), select Binary as the file type (see Figure 24.37), and then click OK to close the Add File FileName dialog.

    Figure 24.37. Adding a comment and setting the options for database file(s) under SourceSafe control.

  5. Click the Add File to $/ProjectName dialog's Close button. The database file(s) are added to the SourceSafe Explorer file list for the project, as shown in Figure 24.38.

Figure 24.38. A local database file added to SourceSafe's file list.

Adding Shared Database Files to the SourceSafe Project

SourceSafe expects all project files to be located in the same local directory. If your application uses database file(s) shared on a server, you must create a subproject that points to the server share as the working folder. To create a subproject containing a database, follow these steps:

  1. In the SourceSafe Explorer window, select the current project (DataWiz for this example).

  2. Choose File | Create Project to open the Create Project in $/ProjectName dialog.

  3. Type the project name and a brief description in the Project and Comment text boxes (see Figure 24.39); then click OK to close the $/ProjectName dialog.

    Figure 24.39. Adding a subproject to a project.

  4. Choose File | Add Files to open the Add Files to $/ProjectName/SubprojectName dialog.

  5. Select the database file to add and click the Add button (see Figure 24.40). Repeat this process for each database file you want to add (if more than one file is required).

    Figure 24.40. Selecting the database file to add to the subproject.

  6. Click Close to close the $/ProjectName/SubprojectName dialog.


Checking in Projects


To check in a project to the SourceSafe database, follow these steps:

  1. Save your project. (You can't check in a project until it's saved).

  2. From Visual Basic 4.0's Tools menu, choose Check In to display the Check In File(s) to SourceSafe dialog.

  3. Only the files you've modified since checking out the project are selected for check in (see Figure 24.41). If you want to check in the entire project, click Select All to mark all of the project files for check in.

    Figure 24.41. The Check In File(s) to SourceSafe dialog that lets you select the files to check in.

  4. Close Visual Basic or open a new project. You receive a message asking if you would like to check in all modified files. (This message box appears despite the fact that you just checked in the modified files). No files are selected to check in, so click Cancel to close the message box.


Viewing File History and Differences


The SourceSafe Explorer provides a variety of tools for tracing the history of and displaying the differences between file versions:

  1. Open the SourceSafe Explorer and select the project in which you're interested.

  2. Select the file whose history and differences you want to view.

  3. Choose Tools | History to display the History of File $/ProjectName/FileName dialog. (See Figure 24.42.)

    Figure 24.42. The History window for the Visdata Check In File(s) to SourceSafe dialog that lets you select the files to check in.

  4. Select an earlier version of the file and click Diff to display the differences between the earlier and current versions of the file (see Figure 24.43). Code additions appear in green color type, changes in red, and deletions in blue.

    Figure 24.43. The Differences window showing the differences between earlier and current versions of a file.

  5. Click Close to close the Differences dialog and then click Close to close the History of File $/ProjectName/FileName dialog.


Summary


This chapter provided a basic introduction to the use of the 32-bit version of Microsoft Visual SourceSafe for version control of Visual Basic 4.0 applications. The 16-bit version of SourceSafe running under Windows 3.1+ is almost identical in operation to the 32-bit version. Publishing limitations preclude a full description of all of SourceSafe's features. SourceSafe is sufficiently sophisticated to require an entire book to present source code control strategies and provide detailed descriptions of all of SourceSafe's capabilities.

This chapter completes Section VI, "Taking Advantage of Enterprise Edition Features." The last section of the body of this book, "Distributing Production Database Front-Ends," covers database application documentation, creating help files, and using the SetupWizard to create distribution diskettes for Visual Basic 4.0 applications.

Previous Page Page Top TOC Next Page