Team software development adds a new layer of complexity to the already challenging world of programming. When multiple developers work on a single project, the danger of one programmer overwriting another programmer's changes is always present. Programmers who are aware of this possibility guard against it by keeping a private copy of each source module they work on. This way, if their changes get stepped on, they can go back to their private copy to cut and paste their work back into the module.
At first, this solution seems reasonable, but this cure can be more deadly than the disease. Code that's added back into a project later can unintentionally affect other pieces of code that other developers add independently. Further, this re-addition can disrupt the software testing process. In the best scenario, the same code is tested multiple times, slowing the development process. In a worse scenario, someone adds the code after the component testing phase, and the added code is never tested. You can imagine how this situation can introduce serious defects. In addition to the multiple developer problem, team application development faces other problems such as version tracking, isolating code differences, and regenerating historical releases.
In the Enterprise Edition of VB 4.0, Microsoft addresses such team development problems by bundling in Visual SourceSafe (VSS)--a version-control application. VSS introduces a much-needed system of checks and balances to the team software development effort and provides tight integration with VB's development environment. Also, you can use VSS for version management of both 16-bit and 32-bit applications. Basic version-control capabilities include source check-in and check-out and advanced features such as visual file differencing, file modification history, and tracking the relationship between project files.
VSS comes in two parts: a server component and a client component. Developers usually install the server component in a shared LAN directory so multiple developers can access it. The server component is the central repository for the shared development projects. The client component provides a link between the client development environment and the server portion of VSS. For VB and Visual C++, the client portion integrates directly into the Interactive Development Environment of each product.
Team Development
Before you can use VSS, you must first set up its administration. VSS comes
preconfigured with two user accounts: Guest and Admin. As you might expect, the
Admin account lets you perform the administrative functions for VSS, and the
Guest account is a sample user account. As shipped, the product has a blank
password for both profiles.
To set up a new VSS account, run the Visual SourceSafe Administration program that was installed into the Visual SourceSafe program group and sign in using the Admin account. Then take the menu option to add a new user. Enter the user identifications and passwords for all the developers who will use VSS. This login is just for VSS, and it's separate from NT's domain login or SQL Server's database login. You can also configure VSS to use the network user name and password, which will bypass VSS's usual login dialog.
After you enter the user accounts, you can have the users run the Client Setup program on their local systems. You can run the Client Setup before adding the user accounts, but if you do, the users won't be able to log in to VSS. The VSS client installation process adds several options to the VB 4.0 Tools menu, as shown in screen A.
Using VSS
After you install the client portion of VSS, every time you save a project
that's not under source control, a dialog appears that asks whether you want to
add the project to SourceSafe. To add the project to VSS, you select the VB 4.0
Add-Ins menu shown in screen B.
From the Add-Ins menu, you select the Add Pro-ject to Source Safe option to add all the project's files to VSS. Additionally, the Open New Source Safe Project option lets you start a new project from scratch. The Run SourceSafe option opens up the SourceSafe Explorer, which lets you work with existing SourceSafe projects. The Options menu lets you customize the operation of VSS.
Selecting the Add Project to SourceSafe option displays a dialog that lets you assign a meaningful name to your project and use the associated list box to define the project's scope. The list box displays all the VSS projects that are already created. You can save your project at the root level, or if yours is subordinate to another project, you can save yours as a sub-project.
After assigning the project name and scope, click on the OK button to proceed to the next dialog. It shows all the files in the VB project. Each file that has an x in the check box will be added to the VSS project. You can also write a comment that helps identify this project to other users of VSS. Pressing the OK button copies all these files into VSS. Note that in VSS, multiple projects can share files.
The next time you work with this project in VB, you must use the Check-Out and Check-In options on VB's Tools menu. VB projects that are using VSS will have a small red lock displayed next to each module in VB's project window. An important thing to remember when you're using VSS is that you never work directly with the files that are archived: You must check out the files to modify them and check them back in when you are finished.
One closing tip: Try to avoid checking in files that are half finished. Although this practice is not always possible when you first start a project, you still aim to keep files checked out at least until they compile and preferably until after they are component-tested. If you follow this simple procedure, you'll know that your developers can always build an executable file from the files VSS stores.
