Sourcesafe physical file

Voice: Fax: Email: troche bstone. In this session, we will look at what SourceSafe is, what it can do for you, and how to implement it. We'll look at issues involved in installation, maintaining and updating installed copies, and how to maintain the database. Finally, we'll look at some third party product that can make SourceSafe easier to use. This document is based on my experiences with Visual SourceSafe 6.

Rumors abound that Visual SourceSafe 7. Past history certainly indicates that with each version of SourceSafe, the issues have changed. Stay tuned. Source code control can be a very useful tool to the solo developer as well as a key tool for multiple-developer teams. For the solo developer, source code control provides backup facilities and the ability to perform a "grand undo" as well as retrieve early builds or versions.

With a multiple-developer team, source code control can ensure that all members of the team work with the latest revision of source code, protect the members of the team from inadvertently overwriting each others work, and provides a simple method to keep track of multiple releases of the software to the same or different clients.

Source code control programs have been around for quite some time but, like difficult backup programs, programs that prove too hard to use are too easy to avoid. With the increasing complexity of projects and the improved accessibility of these products, they are tools are worth the effort to learn. Integration of source code control directly into the development environment is a relatively recent feature that makes these programs easier to use.

Bear in mind that Visual SourceSafe, or any other source code control program, is its own product and you must learn its terminology and operations to get the greatest benefit from it. While many operations can easily be performed from within the FoxPro interface, you should become familiar with the less frequently needed maintenance functions that may only be available within the program itself.

Installation of Visual SourceSafe is a two-step process: first, the data structures, administrative tools, and the setup for the client tools is loaded onto a network share the "Server Installation" and then the client tools setup is run, either from this installation, or from the original source media.

This is a pretty standard Microsoft install program, without too many surprises. Ensure that the target directory for the server install is accessible from your workstations. A problem with this model occurs when the inevitable service pack appears. Service Packs are designed to update the configuration on individual machines, and not on both server and client installs. When the Service Pack is run on the server machines, only the binary files are updated; the setup files for the client install still contain the original files.

Each future installation of the client software from the server will also require that the Service Pack be run on the target machine after the installation. In past versions of SourceSafe, Microsoft has provided the instructions to manually update the client installation files to the latest service pack, but unless a large number of installations must be performed, this is both more time-consuming and difficult that just running the Service Pack on each client machine.

Currently, Visual SourceSafe maintains its own user list and, if enabled, individual rights can be granted or revoked on individual projects. While most small development shops will not want to add the administrative burden of maintaining this feature, larger shops often find it necessary, and an onerous task to maintain. It is hoped in future versions that integration with the Windows security model, with the ability to assign group rights, will make this task much easier.

Since Visual SourceSafe maintains source code as separate files on disk, and since anyone with permission to use SourceSafe must have complete rights to the data directories, login and security are really only an inconvenience to someone determined to access source code. If tighter security is required, setting up separate databases and using the network rights mechanism is required to prevent unauthorized access to source code.

Figure 1 : Multiple checkouts should be turned on. Analyze is an essential utility for analyzing the health of a VSS databases, detecting inconsistencies and errors, repairing some of the more simple errors, and compacting unused space in the database.

The results of Analyze can be a little difficult to decipher, but the Administrator help file and also Microsoft KnowledgeBase article Q list the more common errors and documents fixes, where available, for these errors.

After making a backup of the database and attempting to fix it, always run Analyze again to verify that the problem has been fixed, and to find out if fixing this error brought forth any other errors the first problem may have been masking.

In many cases, the Analyze, Backup, Fix cycle may need to be run several times. With the tools available within Windows NT or Windows , it is not difficult to set up a scheduled task to run the Analyze program on a regular basis, and send the results to a text file. From there, you can process the file into your email system, compare it against previous values, or parse it in FoxPro to determine if actions are required.

Visual SourceSafe stores the entire tree of source code, as well as the tree structure itself, as a large number of files. The files are generated with a sequential series of alphabetic names. Zero kb, and unable to get previous versions. Days of work potentially lost. We then copied the contents of ismaaaaa. The moral of the story: use the above scripts as a starting point to troubleshooting, repairing, and archiving your SourceSafe databases.

Ben worked for a variety of tech startups in Chicago before moving to Portland and starting DevelopmentNow in When he's not herding cats, stirring pots, and taking names, he enjoys drinking coffee while irritating the studio audience with bad puns.

Visual SourceSafe uses the concept of a current project. The SrcSrv indexing script respects this value and limits processing to those source files that are part of the current project. To display the current project, use the following command:.

For example, to process all projects, set the current project to the root:. Visual SourceSafe projects are associated with working folders. A working folder is the location on the client computer that corresponds to the root of a project. However it is possible for such a computer to obtain and build source without a working folder being specified, usually when creating projects through the Visual Studio interface or by using the command:.

However, this mode of operation is incompatible with SrcSrv indexing. SrcSrv requires that a working folder be specified. To set the working folder, use the command:. Visual SourceSafe cannot determine what version of a file exists within the working directory of a build machine. Consequently, you must use labels to stamp the project with an identifier that is used to extract source files on the debugger client.