Share this page
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.
Transactions are Immutable
Once a transaction is recorded in the metadata stored for the depot, it’s there permanently. There is no way to revise or delete an existing transaction — the transaction is immutable. This property is essential to successful configuration management. Users must be able to recreate previous configurations with absolute reliability. The immutability of transactions means that users can reproduce any previous configuration, not just a few configurations that they happened to “label”.
AccuRev does make it easy to undo the effect of a transaction. For example, the revert command reinstates an old version of one or more elements. B
Transactions and Workspaces
This section describes how AccuRev uses a depot's transaction history to efficiently manage the contents of the depot's workspaces.
Over time, the version-controlled elements in a workspace change in two ways: you modify certain files yourself, using text editors and other development tools; and you periodically use the update command to get copies of the files that your colleagues have modified. Accordingly, at any given moment the version-controlled elements in a workspace fall into two categories:
-
Files placed in the workspace by the ‘update’ command. All of these files are unmodified copies of the versions in the workspace’s backing stream at the time of its most recent update. Some of these files may have been placed in the workspace during previous updates. Typically, some files are copied into the workspace when it is originally created and are never touched thereafter, because no new versions of the files are ever created in the backing stream.
AccuRev records the fact that the workspace is up-to-date as of the transaction that most recently precedes the time of the update. (This is completely accurate — no new versions could have been created between that transaction and the update.) This transaction is called the current update level of the workspace.
-
Files that you’ve worked on in the workspace. These are files that you’ve modified (or newly created), and whose changes you’ve preserved with the keep (or add) command. You may also have promote’d the latest version you created to the workspace’s backing stream.
AccuRev can quickly fulfill a request to update the workspace, because it doesn’t need to consider every file in the depot. Instead, it needs to process only the files that have gotten new versions since the workspace’s last update that are visible in the workspace’s backing stream. It accesses these versions by examining the set of transactions between the workspace’s current update level and the most recent transaction. When the update is complete, the most recent transaction becomes the workspace’s new update level.
Transactions and Issue Management
The atomicity of transactions makes it efficient to implement the integration between AccuRev’s basic version-control facility and its issue-management facility (AccuWork). Suppose a particular AccuWork issue record contains a bug report. When you fix the bug by modifying five files, you’ll want to note this fact in the issue record. AccuRev can simply note the single promote transaction that placed the fixed versions of the five files in the backing stream. Alternatively, you can have AccuRev keep track of the individual versions in the issue record; in this case, the issue record acts as a change package, recording all the versions that were created to implement a particular bug fix or new feature.
