1. The AccuRev Data Repository

As a data management product, AccuRev’s foremost job is to provide a secure data repository for long-term storage of your organization’s development data. AccuRev’s implementation of the repository is straightforward and flexible, and key product features make it easy to protect the repository from accidental or malicious damage.

AccuRev has a simple client-server architecture. While the AccuRev Server (accurev_server) is running, it is the only program that accesses the data repository. This “single point of entry” to the repository makes it easy to enforce tight security at the operating system level.

The data repository is built around a database technology that is transaction-based and manages most tables as append-only. This makes the repository extremely resistant to accidental damage. Using “atomic” transactions means that the database won’t become corrupted, even if a power failure occurs while the database is being modified. The append-only feature enables “live backup” of the repository, without having to interrupt developers’ work. This means that backups can be made as often as desired — even continually.

Organization of the Repository

An AccuRev data 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 records. (For licensing purposes, AccuRev’s issue management capability is termed “AccuWork”.)

•	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.

The illustration below shows the modular structure of the AccuRev data repository. Logically, the entire repository is located on the machine where the AccuRev Server program runs, but only the accurev database must physically reside on the server machine. The file storage areas — which typically are far larger than the databases and grow far faster — can be located elsewhere. For example, the file storage area of depot jupiter might be located on another disk on the AccuRev server machine, and the file storage area of depot saturn might reside within the local area network’s disk farm.

Single Depot vs. Multiple Depots

You can place all version-controlled files in a single depot, or split them among multiple depots. In general, we advise storing all files for a given project in the same depot. By “project”, we mean all the programs and other software deliverables that share the same development/test/release procedures and the same release cycle. The procedures determine how a depot’s stream hierarchy will be structured; the release cycle determines how the stream hierarchy will be used.

If Project_X and Project_Y have completely different release cycles, then put their source files in different depots. Likewise, if Project_A requires stringent in-house regression testing and two levels of beta-testing, whereas Project_B is mandated to “ship yesterday”, use different depots.

Note: when using the include/exclude (cross-link) facility, you can have a single depot serve multiple partially-independent or totally independent projects. See The Include/Exclude and Cross-Link Facilities on page 17.

AccuRev has no problem in storing thousands, tens of thousands, or even hundreds of thousands of files in a single depot.