2. The AccuRev Repository

The AccuRev Server program manages a data repository, which provides long-term storage for your organization’s development data -- for example, all versions of all source files. The repository consists of:

•	A database called accurev, which contains:

•	A site schema, which contains the user registry, list of depots, list of workspaces, and other repository-wide information.

•	A schema for each depot, each of which contains depot-specific metadata and AccuWork issue data.

•	The site_slice directory, which contains repository-wide AccuWork data, workflow configuration data, server preferences, and triggers

•	The depots directory, which contains a set of subdirectories, each storing an individual depot. A depot subdirectory stores one or both of:

•	A version-controlled directory tree: all the versions of a set of files and directories.

•	AccuWork schema, query, and change package configuration data.

When it starts, the AccuRev Server program determines the location of the site_slice and depots directories by looking at the settings in configuration file acserver.cnf. This file must reside in the same directory as the Server program (accurev_server) itself. See Server Configuration File on page 16 for more information.

Repository Access Permissions

The operating-system user identity of the AccuRev Server process must have full access to all the files and directories within the storage directory. For maximum security, this should be the only user identity with permission to access the repository.

If you create an acadmin AccuRev administrator account, as suggested in Operating-System User Identity of the Server Processes on page 13, this user identity must also have access to the bin directory where the AccuRev executables are stored.

READ ME NOW: Assuring the Integrity of the AccuRev Repository

The integrity of the AccuRev repository is critically important. If information in the repository is lost or corrupted, your organization's ability to do business may be severely compromised. The integrity of the repository relies on the integrity of underlying software (the database software and the file system, including the device drivers for data storage devices) and underlying hardware (the data storage devices themselves). Certain practices will enhance the safety and reliability of these underlying facilities. We strongly recommend that you:

•	Use high-quality disk drives and disk controllers.

•	Reduce the impact of a hard-disk failure by using disk mirroring (for example, using a RAID system) or other fault-tolerant disk subsystems.

•	Power the AccuRev server machine with an uninterruptible power supply (UPS), with automatic shutdown of the server machine if the UPS is running out of power. This reduces the likelihood of interrupted data transfers to disk.

•	Establish a good data-backup regimen, and make sure your backups are reliable by doing test restores on a regular basis. (See Restoring the Repository on page 8.)

This section focuses on one aspect of data integrity: guaranteeing “write” operations to the repository. The AccuRev Server process does not, itself, perform the act of writing data on the disk. Like all application programs, it makes a “write” request to the operating system (UNIX/Linux, Windows). In turn, the operating system performs a “write” operation to the disk itself. (On some larger systems, there may be additional links in this chain of write operations.)

Operating systems and disk subsystems often use special techniques that boost the performance of write operations, but can compromise data integrity. For example, when an application program makes a write request, the operating system might:

•	Acknowledge the request immediately — good, because the application program can then proceed to its next operation.

•	Delay actually sending the data to the disk (“write-behind”) — bad, because a system failure at this point might result in the data never being stored on the disk.

It is essential that such techniques not be used when the AccuRev Server process sends information to the disk containing the AccuRev repository. The Server always follows each write request with a “synchronize the disk” request. Sometimes, this ensures that data is safely on disk before the Server proceeds to its next task. For example, this is typically the case if the repository is stored on a disk that is local to the machine on which the Server is executing.

But in some situations delayed-write techniques may be used even when the AccuRev Server makes “synchronize the disk” requests. This is typically the case if the repository is located on a network shared file system. In such situations, the Server's “synchronize the disk” requests are effectively ignored, so that successful completion of write operations to the AccuRev repository cannot be guaranteed. (Some disk subsystems implement such a guarantee by having their own battery backup; buffered data is flushed to disk when the power fails.)

In an attempt to avoid such unsafe situations, the AccuRev Server process attempts to determine whether the file system where the repository is stored guarantees the successful completion of write operations. If it decides “no”, the Server refuses to use the repository. This determination is not foolproof — both “false positives” and “false negatives” are possible.

If you have any question about the safety of your data-storage system, please contact AccuRev Support Services.