© 2001 Microsoft Corporation. All rights reserved.
Other product and company names herein may be the trademarks of their respective owners.
Visual SourceSafe Readme includes updated information for the documentation provided with Microsoft Visual Studio -- Development System for Windows® and the Internet. The information in this document is more up-to-date than the information in the Help system.
Contents - Click any of the items below
Visual SourceSafe (VSS) version 6.0c is a re-release. It contains a modified installation program and updated VSS files containing all the new features and bug fixes since the VSS 6.0 release
The installation program for VSS 6.0c has been modified to ensure an upgrade of your existing VSS 6.0 installations. For the latest installation notes, see Installation.
Users that do not log in as an Administrator or Power User on the local computer cannot access a local SourceSafe database when it is installed on a Windows 2000 or WindowsXP NTFS partition. Attempts to access a SourceSafe database under these conditions raises the following error, "Unable to open user login file ...\VSS\data\loggedin\username.log" where username is your SourceSafe login name.
To work around this issue either install the SourceSafe database to a UNC path or log in as a Power User or Administrator.
For more details about this issue, see http://www.microsoft.com/windows2000/techinfo/planning/security/secdefs.asp.
Novell NetWare servers can be configured to handle either long file names or file names in the 8.3 file name format. If the Novell NetWare server can handle only file names in the 8.3 format, the regular Visual Studio installation process cannot install on the Novell NetWare server. To install VSS on a Novell NetWare server that can handle only file names in the 8.3 format, use the following steps.
To install from the Visual Studio compact discs (CDs):
To install from the Visual SourceSafe standalone CDs:
Difference for File Dialog Box topic — In the Dialogs section of the Visual SourceSafe documentation, the first paragraph in the Remarks section is incorrect.
Current text: This dialog box is used only when you have not selected the visual difference comparison. (For visual differences, make sure you select the Visual option from the Difference Options dialog box.) By default, VSS uses the Visual Difference dialog box.
Correct text: This dialog box is used only when you have not selected the visual difference comparison. (For visual differences, make sure you select the Visual option from the Difference Options dialog box.) By default, the Visual option is selected, and VSS uses the Differences for <filename> dialog box with options specific to visual differences.
In the File History Options Dialog Box topic of the Visual SourceSafe Documentation, the first sentence of the Labels section is incorrect.
Current text: Includes only labels in project history if you have selected the Include file checkins option.
Correct text: Includes only labels in project history if you have selected the Include file histories option.
In the Advanced Check Out Options Dialog Box topic of the Visual SourceSafe Documentation, the Replace option is incorrect.
Current text: Replace — Replaces the file with a read-only version.
Correct text: Replace — Replaces the file with a writeable version.
In the Advanced Check Out Options Dialog Box topic of the Visual SourceSafe Documentation, the End of Line option has been removed.
In the Advanced Get Options Dialog Box topic of the Visual SourceSafe Documentation, the End of Line option has been removed.
VSS 6.x handles MBCS (multibyte character sets) and DBCS (double-byte character sets) differently from earlier versions of VSS. If you are upgrading an existing installation of VSS that has a file called ssud.dll, rename it so that VSS 6.x does not recognize it. For example, rename the file to ssud.bak. If you do not rename it, you may have trouble in the input method editor (IME) with font association (FA) turned off or it may generate GPFs when dialog boxes that are new to VSS 6.x are displayed.
Visual SourceSafe cannot handle Unicode files. When a file is first added to SourceSafe, SourceSafe automatically detects whether the file is in text or binary format. If Unicode files are added as text format files, SourceSafe can corrupt them.
To work around this issue, add all Unicode files to SourceSafe as binary format files. You can override the file type automatic detection feature by clicking the Advanced button in File Add dialog box when you are adding a file. If the Unicode file has already been added, you can access the file properties in SourceSafe and change the file type to Binary.
The Technical Support phone number (900) 555-2300 is no longer in service. If you need techncial support, go to the Product Support Services page on the Microsoft Corporation Web site (http://support.microsoft.com/directory/). The fees are:
When you run the VSS 6.0c Setup program on a computer that has VSS 6.0 with SP1, SP2, SP3, SP4, or SP5 installed, the Setup program displays the following message:
The Installation Wizard has detected an older version of Visual SourceSafe 6.0 installed on your computer. Visual SourceSafe 6.0c does not support side-by-side installation with other versions of Visual SourceSafe 6.0. The topic "Side-by-Side Product Installations" in the Visual SourceSafe 6.0 readme describes the valid configurations that Visual SourceSafe 6.0c supports. To upgrade your existing Visual SourceSafe 6.0 installation with Visual SourceSafe 6.0c, continue with Setup and accept the upgrade installation path when prompted.
Do you want to continue?
This warning is valid because installing VSS 6.0c side by side with VSS 6.0 is not supported. Answer Yes to this message and to a subsequent message asking you if you are certain you want to continue.
When Setup continues, it states that you have an older version of the product already installed and asks whether you would like to upgrade it. Click Next to accept the selected folder location. When prompted for the specific installation type, select the type already installed on your system.
The source code control database maintained by VSS must be on a drive that is accessible to all users working on projects controlled by VSS. The most versatile method of working with VSS is to perform a server installation to a network drive and a Netsetup installation on each workstation.
You will be prompted to replace an existing installation if found. This is recommended, but you can choose an alternate path and then maintain two different databases, one in the old format and one in the new format, on the same computer.
Note Make sure you back up the database before you upgrade.
You will be prompted to convert your database to the new format for faster performance. You should do this only if:
Be aware that a VSS license is required for each user of Visual SourceSafe. For example, if you have 100 people using your VSS database, you must purchase 100 Visual SourceSafe licenses to avoid violating copyright law.
The version 6.0c Netsetup program requires a CD-Key before it can install the Visual SourceSafe client software on a client computer. To make sure your clients can run Netsetup successfully, provide a CD-Key from one of your licensed boxes to each user. You can reuse the same CD-Key for everyone running Netsetup, but you are still required to have an individual license for every user.
Note A Visual SourceSafe license for each client is required to use Netsetup.
- or -
Visual Studio products with the same version and in the same language—Visual C++® and Visual Basic® version 6.0 in English, for example—can be installed separately on the same workstation. Microsoft supports such installations. The Visual Studio 6.0 Installation Wizard detects if other versions of the 6.0 product line have been installed on a workstation.
Mixing different language versions, point releases, or product tiers on the same workstation are generally not supported. This means that the installation can fail, one or more of Visual Studio 6.0 products may not work even if the installation succeeds, or in the worst case, you may not be able to remove any of the products completely.
If the wizard generates a warning during installation, the safest action is to uninstall the Visual Studio 6.0 product before proceeding. The detection scheme checks for the following scenarios:
|
Product |
Supported Installation |
|
Visual Basic |
Install in two different locations |
|
Visual C++ |
No side-by-side installation is supported. |
|
Visual FoxPro |
Install in two different locations |
|
Visual InterDev |
Install in the same location. You must reinstall after removing one version. |
|
Visual J++ |
Install in the same location. You must reinstall after removing one version. |
|
Visual SourceSafe |
Install in the same location. You must reinstall after removing one version. Note The UI language chosen when you run Visual SourceSafe is based on the system's language settings. If that language is not installed for Visual SourceSafe, it uses English instead. |
|
MSDN |
Install in default directory. |
After an administrator has created a VSS installation on the server, users can run NetSetup to copy the VSS executable files to their hard disk.
To install using NetSetup:
Warning to Administrators All users, including anyone running Netsetup, must have an individual VSS license to install and/or use the product. Netsetup is provided as a convenience, but the administrator should make sure to obtain individual licenses for each person that installs and uses the product.
If you were prompted to upgrade your database to the new 6.x format and you clickedYes, you now have a 6.x database and can take advantage of label promotion and enjoy performance enhancements. If you weren't prompted or you clicked No to the prompt and you now want to upgrade your database, run the DDUPD.exe command-line utility, which exists in the \win32 directory of your VSS 6.x server installation. (You can either go to that directory and run it or add that directory to your path and run it.) We recommend you run DDUPD only when everyone has quit VSS. The syntax is:
DDUPD <path to data folder> [-undo] [-redo]
To upgrade a 5.0 database, for example, you would run:
DDUPD \\server\share\vss\data
To undo an upgrade, return to the version 5.0 format and stop taking advantage of the performance enhancements and label promotions:
DDUPD \\server\share\vss\data -UNDO
To redo the upgrade process on a database that is already in the new format, run:
DDUPD \\server\share\vss\data -REDO
If you delete a VSS installation (including the database) and then attempt to run Setup, Setup may try to install VSS in the Recycle bin (if the old database is found here). This happens only if the Recycle bin hasn't recently been emptied. To remedy the problem:
Microsoft VSS 6.0 adds many new features. Some of the highlights include:
It is still advisable to back up the drive where your VSS database resides regularly. It is important to use full backups, not incremental or differential backups, to avoid problems.
In addition, you should run the ANALYZE program periodically to maintain database integrity. If a corruption is found, the ANALYZE program can usually repair the problem. Updates to the ANALYZE tool are posted periodically on the VSS Web site, http://www.msdn.microsoft.com/ssafe. You can check that site to see if there is a version of ANALYZE more recent than the one shipped with this product.
To run ANALYZE:
Note It is always advisable to run the Analyze utility and back up older databases before upgrading them to the 6.x format.
If you are using VSS on a remote database and you lose your connection to the server, the following error occurs:
"unknown error - 20038," (or similar)
If you see this error, you have lost your network connection.
To correct the situation
VSS uses the date and time that your local computer stores. If your computer is not synchronized with other computers, unpredictable results can occur. For instance, you check in a file after someone else, but VSS determines your checkin happened first because your system clock was off!
The best solution for this problem is to synchronize your local date and time with the network on a regular basis. With Windows NT this can be done with a Domain Time Source Server. Check the http://www.novell.com/ site for information on time synchronization with Novell NetWare servers.
If you are working from the command line and receive the following message "No VSS database (SRCSAFE.INI) found. Use the SSDIR environment variable or run netsetup.", set the SSDIR variable. This tells VSS where to find the Srcsafe.ini file for the VSS server installation to which you want to connect. You can do this by typing the following at the command prompt:
set ssdir=\\server\share\vss
Where \\server\share\vss is the folder where the Srcsafe.ini file is located.
Note There should not be a space between the equal sign and the location of the VSS server installation. For example, the following will not work:
set ssdir= \\server\share\vss.
A shadow folder is a live mirror (on the file system) of the projects in the Visual SourceSafe (VSS) database.
For a shared database, you must set up the shadow folder with a Universal Naming Convention (UNC) path, such as \\Server\Share\Shadow, to avoid failure when changes are made from a computer other than the one used to set up the shadow. Make sure the UNC contains no long names, just eight-character short names for the \\Server\Share\Root portion.
For example, instead of defining the shadow folder as D:\VSSShadow, you can define the shadow folder as: \\server\D\Shadow.
Confirm that all the Visual SourceSafe users have read/write access to the UNC directory.
Due to a problem Windows 95 has accessing some programs on Windows NT Server computers through a UNC that contains long names, you should create a network share on the Windows NT Server computer that points directly to the VSS location on the server's disk drive, and avoid long names for the server and share names.
For instance, if VSS is installed to:
D:\Program Files\Microsoft Visual Studio\Common\VSS
You can provide users access to it by setting:
D:\
shared as
\\Long Server Name\Long Share Name
And they would then access it with:
\\Long Server Name\Long Share Name\Program Files\Microsoft Visual Studio\Common\Vss\Netsetup.exe
The long names cause computers running Windows 95 to fail when the server is a computer running Windows NT.
Instead, set it up with:
D:\Program Files\Microsoft Visual Studio\Common\VSS
shared as
\\Server\VSSShare
In this way, users can access Netsetup.exe with the following short UNC:
\\Server\VSSShare\Netsetup.exe
Microsoft VSS has a home page on the Internet. This home page features a variety of information including articles on VSS, a self-running demonstration that you can download, a collection of helpful VSS utilities, and much more. The URL for the home page is: http://www.msdn.microsoft.com/ssafe.
If you encounter problems or have questions not addressed here or in the online documentation, you can search the Microsoft Knowledge Base at http://support.microsoft.com/support. The Knowledge Base is also available on the MSDN Library Visual Studio 6.0.
You can exchange information with other VSS users by visiting a newsgroup on the Internet. For details, see http://communities.microsoft.com/newsgroups
Note Microsoft does not provide support for messages posted to the newsgroup.
The most up-to-date SourceSafe Best Practices Guide can be found at: http://msdn.microsoft.com/library/en-us/dnvss/html/vssbest.asp?frame=true. This guide is in English only.
Under normal operation in a stable environment, Visual SourceSafe provides excellent storage and security for your current source data and past revisions. However, as with any database product, data corruption can occur. This section outlines recommended practices to help avoid corruption problems. Although all the practices can help minimize the impact of corruption, one of the most valuable is using a data repair utility called Analyze. The Analyze tool ships with Visual SourceSafe. It checks for and repairs many common data write errors. Run Analyze on your Visual SourceSafe database with your regular tape backup schedule to ensure the stability and security of your source data.
Important When using Visual SourceSafe, make sure that you are running the latest version of the applications. Microsoft periodically releases service packs for our applications that correct known issues. We recommend that you install the service packs as soon as possible.
Customers who want to upgrade their Visual SourceSafe client to the latest Visual Studio Service Pack releases should use the Service Pack installations instead of running netsetup.exe again.
Under normal use, your Visual SourceSafe database should not exceed 3 to 5 GB. To determine an appropriate size, consider the amount of free space on the server, the relationship among the projects being stored, the amount of file history you need to access quickly, and user tolerance for reduced performance. Although Visual SourceSafe does not have a size limitation, on very large databases it takes longer to perform normal operations and maintenance tasks, such as running Analyze. Visual SourceSafe does not limit the number of databases you can put on a server.
To reduce potential file size, keep projects that are not interrelated in separate databases. You can use the Archive and Restore utilities included in Visual SourceSafe version 5.0 and later to move projects to another database or to remove outdated history from a project.
Although you can store Visual SourceSafe databases on any Microsoft Windows®-compatible file server (Windows NT, Novell, Banyan, and so on), database performance is best on Windows NT. Network operations are generally faster. In addition, in the server-based Windows environment you can run Analyze and other highly intensive file I/O operations directly on the server, often dramatically decreasing execution time.
Use the Analyze tool shipped with Visual SourceSafe to detect and repair problems in the database structure. When you run Analyze regularly, especially in high-use situations, you can discover small problems and fix them before they become worse. Run Analyze weekly or, at minimum, monthly as part of regular maintenance.
While running Analyze directly on your production database, you must lock out users. To minimize the impact, restore your regular backup to another location and run Analyze on that copy. Another way that you can create a duplicate on-line copy of your VSS database is to use the ROBOCOPY utility from the Windows NT Resource Kit. This utility copies all the files in a folder and subfolders; however, if a file is in use, it will retry the copy instead of just failing. You can use this method to create a backup of your database on another server as well. If you detect problems in the backup that need to be resolved, you can then lock out users from the production database while making any necessary fixes. If Analyze returns no errors, you do not need to interrupt user connections. This method also checks the validity of the backup strategy.
Each time you run the Analyze utility, create a list of all items in the database. This list is useful in determining which logical file name is related to an error based on the file name (for example, Abcaaaaa.a) for which the error is reported.
To create the physical list
SS PHYSICAL $/ -R–O@PHYSICAL.TXT
For more detailed information on Analyze, see Finding and Repairing Data Corruption later in this document.
Caution Do not allow Visual SourceSafe or the Analyze tool to run out of disk space while running. Running out of disk space in the middle of a complex operation can create serious database corruption.
Visual SourceSafe does check for disk space. However, due to performance concerns, it does not check for space on every disk write operation. To avoid possible database corruption, make sure there is enough free space on the server so that a complete copy of the database can be created during normal Analyze operations.
Use the Sharing and Branching features of Visual SourceSafe with discretion. Avoid Sharing or Branching across top-level projects because it complicates the process of archiving a project and restoring it into another database. Moreover, when you branch files and then delete them, the space is not recovered until all copies of the branched file in the database are destroyed.
The acceptable number of users varies depending on the performance of the server and the network. When you control the size of the database, performance improves, and more users can access the database with reasonable performance. The number of full-access users you have determines the number of licenses that you need for Visual SourceSafe.
All users must have create, modify, change/edit, and delete permissions for files in the Data folder and its subfolders in the directory tree. These permissions must also be applied to the share permissions. If a user receives the message “Unable to create user login file,” that user does not have the proper permissions to the VSS database location.
Each database has its own User and Rights management systems. You cannot interrelate these files.
Users' Ss.ini files are limited to 64 KB and a maximum of 10 different computer-specific settings. Each time a user logs on from a different computer, the Ss.ini saves the window positions and other computer-specific information. If you are experiencing unusual user-specific problems, try deleting unnecessary entries in the user's Ss.ini file.
To maintain file integrity, make sure that all users have their own working folders for all projects. When multiple users share a working folder, a file checked out by one user can be modified by anyone with access to that folder. Maintaining separate working folders ensures that users modify only files they have checked out themselves.
Synchronize the dates and system clocks for all Visual SourceSafe client computers with the Visual SourceSafe server. This prevents checkin and checkout operations from appearing to happen out of sequence and affects any labels that are applied. Synchronizing dates and system clocks is particularly important when users from different time zones access the same database.
You can set up a computer running Windows NT Server to act as a Domain Time Source server for users to synchronize their local date and time with the network. For additional information, see the Knowledge Base article "How to Set Up and Synchronize with Domain Time Source Servers (search on article ID Q131715).
Avoid creating a new database by copying an existing one. Doing so can potentially cause problems because the globally unique identifier (GUID) in the Um.dat will be the same for both databases. For details on how to create a new database, see Knowledge Base article Q123467, "How to Create a New Database in SourceSafe."
To move a Visual SourceSafe installation, copy the entire VSS folder and all of its subfolders to the new location. However, do not use XCOPY to do this because it does not copy some zero-byte files. Instead, use Windows Explorer to copy the folder(s). After you have copied the installation, Visual SourceSafe clients must change the #include statement in their local Srcsafe.ini file to reflect the new location. No other modifications are necessary. To move just the database itself, perform the same operation on the Data folder and then modify the DATA_PATH line of the server Srcsafe.ini instead of the client Srcsafe.ini. When specifying the DATA_PATH, use the UNC method (\\SERVER\SHARE). For details, see Knowledge Base article Q176909, "HOWTO: Move a VSS Database or Project to New Location."
Tip After you have moved the VSS location, you can create a Srcsafe.ini file in the old location with a #include statement pointing to the new SrcSafe.ini location. This provides time for users to change their links.
When using Visual SourceSafe through the integration in the development environments (Microsoft Visual Basic®, Microsoft Visual C++®, Microsoft Access, Microsoft FrontPage®, and so on) use the integrated component to perform Visual SourceSafe operations that can be done within that environment. For example, do not check out and check in files from both the Visual SourceSafe Explorer and integrated environments. This is very important because Visual SourceSafe does not understand the links between the source files the way the integrated development environment does. For instance, in Visual Basic a form can be made up of a FRM and a FRX file. Visual Basic knows to check out both files at the same time, but SourceSafe does not. Checking only one file out in the Visual SourceSafe Explorer causes the files to get out of sync in Visual Basic and hence corrupted.
Visual SourceSafe is a file-based version control system that is designed for use on multiple, industry-standard network servers. No special program needs to be run on the server during normal use. The core of a Visual SourceSafe database is the Data directory; it has a unique structure that is designed for maximum flexibility. A Visual SourceSafe database consists of the following files and folders.
|
File/folder |
Description |
|
SrcSafe.ini |
Visual SourceSafe database global settings and configuration information for all users. |
|
Users.txt |
List of all users of the Visual SourceSafe database. |
|
Data\Aaaaaaaa.cnt |
Physical name of last file added to the database. |
|
Data\Crcs.dat |
CRC information used to speed up the get and check-out processes (Visual SourceSafe 6.0 format databases only). |
|
Data\Names.dat |
Long file name information. |
|
Data\Rights.dat |
User and project security information. |
|
Data\Status.dat |
Visual SourceSafe Explorer cache file (used to speed up the display of the Visual SourceSafe Explorer). |
|
Data\Um.dat |
User management information (names and passwords) and the database identifier (GUID). |
|
Data\Version.dat |
Visual SourceSafe database version. |
|
Data\A…Z (folders) |
Folders containing log files and data files. |
|
Data\Backup (folder) |
Contains analyze log file (analyze.log), list of bad files (analyze.bad), and backups of files changed by Analyze. |
|
Data\Labels (folder) |
Label cache information used for label promotion (Visual SourceSafe 6.0 format databases only). |
|
Data\Locks (folder) |
Used if Visual SourceSafe locking is enabled. |
|
Data\Loggedin (folder) |
Contains user logon files and an Admin.lck file if the database is locked. |
|
Users (folder) |
Contains Template.ini, which stores default values for the Ss.ini file for new users. The Users folder also contains a subfolder for each user. This subfolder contains an Ss.ini file defining user-specific settings. The Admin folder also contains Ssadmin.ini, which defines administrator settings. |
Visual SourceSafe creates two files in the Data directory for every file and project that you add to Visual SourceSafe (with one exception described later in this section). These file pairs are distributed evenly across the A through Z subdirectories in the Data directory. The file without an extension (such as QRBAAAAA) is the log file for the file type being stored. The log file contains internal information for Visual SourceSafe, such as who added the file, where it exists, and all the differences between the versions of the file. The file with an .a or .b extension (such as QRBAAAAA.A) is the most recent version of the actual file, stored under a Visual SourceSafe physical name. Each time a file is checked in, the extension it is saved with alternates between .a and .b.
When a user checks in a file, it is copied from their working directory to the Data directory and renamed with the physical name and either an .a or .b extension, whichever is not currently there. Visual SourceSafe then calculates the differences between the .a and .b files and stores it in the log file (the file without an extension). After the log file is updated, the old copy of the data file is deleted. Under normal circumstances you should never have both .a and .b extensions for one physical file name.
Caution Never rename an .a or .b file in the DATA folder. Although doing so appears to correct the immediate problem that you are experiencing (such as: The file QRBAAAAA.A not found.), it will make the previous versions of the file unrecoverable. If you receive this error, restore the file pair from a recent backup.
When you share a file from another project, no new file pair is created in the Visual SourceSafe database. Instead, Visual SourceSafe creates a reference in the original file's log, noting that the file also exists in another project.
Use the Analyze tool, located in the Microsoft Win32® directory, to check for and correct corruption problems. You should run it as frequently as is practical—once a week is recommended, or at a minimum, once a month. Analyze checks all the files in the Visual SourceSafe Data directory for corruption or disconnected links and often repairs these with proper switch settings. Because Analyze is so thorough, it can be slow to run. The amount of time that Analyze takes to run depends on the contents and structure of the database, such as the amount of sharing and branching and the total number of files.
For best performance, all users should log off Visual SourceSafe before you run Analyze.exe. If you use the -F switch to repair problems, users must log off. However, if you want to run Analyze.exe without requiring users to log off, you can use the -X switch.
Note Due to the amount of file I/O required, you can dramatically improve performance by running Analyze locally (that is, on the server) rather than across the network.
Analyze has several switches you can use to tell it what to do when running. Do not try to use every switch at once. The more Analyze is required to do, the longer it takes to run.
When you run Analyze, it executes in the following four passes.
Analyze supports the following switches.
|
Switch |
Description |
|
-B<folder> |
Specifies the folder to use for backup. |
|
-C |
Compresses unused space. (This simply removes blank space and does not compress the log files.) This pass can generate a large number of files in the backup folder and should be used only when there is plenty of disk space available. |
|
-D |
Deletes unused files. |
|
-DB |
Deletes the Backup folder. Caution If you find corruption, create backup copies of logs before running Analyze with the -DB switch. |
|
-F |
Automatically fixes corrupted files. (Requires users to log off database.) |
|
-I- |
When the analysis is complete, the program quits. (Useful if running in a batch script.) |
|
-V1 |
Displays only critical errors. (This is the default setting, if no -V switch is used.) |
|
-V2 |
Displays only significant errors. |
|
-V3 |
Displays all errors and inconsistencies. |
|
-V4 |
Displays errors, inconsistencies, and informational notes. |
|
-X |
Does not attempt to lock the database when analyzing. (Recommended only when users must remain logged on while Analyze.exe runs; -X cannot be used with -F. If Analyze tries to access a file that is in use while in this mode, it will quit and you will need to re-run it at a later time.) |
Running Analyze in the following order provides good coverage.
|
Command line |
Description |
|
Analyze –V4 <database path> |
The first pass should always locate problems before trying to fix them. |
|
Analyze -F –V4 <database path> |
If errors are reported in the first pass, run Analyze again in fix mode to correct them. |
|
Analyze -F -C –V4 <database path> |
Run this pass when you have “Found a DIFF” and “Found a COMMENT” errors that you want removed. Caution Since the DIFF and COMMENT messages can occur in a large number of files, it is extremely important that you have enough disk space available when running a Compress pass on your database. |
Each time Analyze runs, it places an Analyze.log file in the Backup folder along with a file called Analyze.bad. The Analyze.bad file contains a list of all files in which Analyze found problems. When Analyze fixes a file, it first creates a copy of the file in the Backup folder so that the repair can be undone if necessary. Each time Analyze runs, it requires that the Backup folder is either empty or does not exist. If there is sufficient disk space, it is a good practice to rename the Backup folders instead of deleting them. This history can prove very useful in troubleshooting corruption issues. The errors and messages reported by Analyze are discussed at length in Knowledge Base article Q152807, "INFO: Error Messages from Analyze Tool of Visual SourceSafe."
Analyze can also re-create the Status.dat, Names.dat, and Rights.dat files. To do this, rename or delete the files you want rebuilt, and run Analyze -F. Analyze re-creates the Names.dat file with the spaces in long file names appearing as underscores. You then need to rename the file using Visual SourceSafe Explorer. The Rights.dat file is re-created, but as an empty structure; you need to add permissions for each user again.
Microsoft occasionally updates the Analyze tool to include more checking or to improve performance. For the latest version of Analyze, visit the Microsoft Visual SourceSafe Web site located at http://msdn.microsoft.com/ssafe/default.asp.
Backups should be performed regularly as part of the daily or weekly file maintenance and security process. When backing up your Visual SourceSafe database, make sure you are getting a full backup of the database. Although you can use incremental backups, you should avoid them because some of the files from the database may not be able to be restored. If users are logged on to Visual SourceSafe and actively using the product, the files they have open will not be backed up by most standard backup utilities. There are several backup and copy utilities that can back up open files. However, if you use these utilities and someone is actively updating a file in Visual SourceSafe when the file is backed up, the backup may be corrupted.
Note Do not schedule Analyze to run at the same time as a backup of the database! If the backup program has files open that Analyze is trying to open, Analyze will shut down unexpectedly.
Visual SourceSafe automatically closes any files opened by Visual SourceSafe or an integrated application after 15 minutes of inactivity. (This requires Service Pack 3 of Visual SourceSafe 5.0 or later.) The user still appears to be logged on to Visual SourceSafe and the files will be reopened when they start working again. However, the Rights.dat and Status.dat files remain open any time users are logged on and will not be backed up. You can rebuild these if needed using the Analyze utility. Each time the administrator modifies the rights by project information for a Visual SourceSafe database, Visual SourceSafe copies the Rights.dat file to a Rights.bak file. If necessary, you can rename the Rights.bak file during a restore process.
Caution Never restore a complete backup of a database over an existing database. Visual SourceSafe maintains very complex links between files. Restoring a whole database backup over an existing database may confuse the links between files and cause incorrect versions of the files to be displayed in the database.
A disaster-recovery study by Contingency Planning Research found that power loss caused 27 percent of data-center disasters in which there was actual data loss in addition to loss of service. This figure includes power outages due to environmental disasters such as snowstorms, tornadoes, and hurricanes. To minimize these disasters, invest in an uninterruptible power supply (UPS). Windows NT Server includes built-in support for UPS.
RAID technology minimizes data loss due to problems accessing a hard disk. RAID is a fault-tolerant disk configuration in which part of the physical storage capacity contains redundant information about the data stored on the disks. You can regenerate the data using this redundant information if one of the disks or the access path to it fails or if a sector on the disk cannot be read.
For information about how to make your server more reliable, see the following resources:
http://www.microsoft.com/windows2000/server/evaluation/business/relavail.asp
http://www.microsoft.com/ntserver/techresources/deployment/NTserver/highavail1.asp