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.