5. AccuRev Transactions

The AccuRev data repository is organized into a set of depots, each of which stores the complete revision history of a particular set of elements. Each depot has its own section of the database. Changes to a depot are structured as a series of transactions, each of which saves all the information involved in a particular change to the depot. Thus, the entire story of how a depot’s elements have evolved is contained in its transaction history.

Transactions are a well-established database technology, helping to guarantee that the database is always in a self-consistent state. But for AccuRev, transactions are not just a low-level mechanism for achieving database integrity. They play an essential role in organizing the user environment. Two aspects of AccuRev transactions make this possible: atomicity and immutability.

Transactions are Atomic

A user command that modifies elements is recorded as a single transaction in the metadata stored for the depot, no matter how many elements are involved. For example, if a user enters a keep command to create new versions of 12 files, a single transaction records all 12 versions. What if something goes wrong (for example, a network failure) while AccuRev is processing those 12 files? The entire transaction is cancelled, and no new version is created. The term atomic describes this “all or nothing” aspect of AccuRev transactions.

The atomicity of transactions makes life simpler for the user. He never needs to worry about how to finish up the work of a partially-successful command. If a command fails, he just fixes the problem that caused the failure and executes the command again. Atomicity also means that AccuRev’s view of the various changes applied to the repository matches the user’s view.

Note: AccuRev does not record every change in a transaction. Keeping a new version is recorded in a transaction, as is promote’ing an existing version to a higher-level stream. But no transaction is recorded when you change the location of a workspace.