Parallel and Serial Development

Like other advanced configuration management systems, AccuRev supports parallel development:

•	Edit Stage. Two or more users start with the same data: a particular version of a file. Each user works on a copy of the file in his own workspace. He can keep as many (private, intermediate) versions as he wishes in his workspace stream.

•

Merge Stage. The merge stage begins when one of the developers promotes his private version of the file to the backing stream. After that, each other developer must merge the current version in the backing stream into his own work, then promote this merged, private version. In the end, all users’ changes are incorporated into the backing stream; conflicting changes to the file, if any, are both detected and resolved.

If two developers work on a file concurrently, a single merge-and-promote operation is required. If N developers work on a file concurrently, then N–1 merge-and-promotes are required.

Serial Development through Exclusive File Locking

Parallel development is flexible and powerful, but it is not appropriate for every situation. Some organizations don't like the extra steps involved in merging, even when merging is largely automated. Some files cannot be merged, because they are in binary format. (AccuRev’s merge algorithm handles text files only, not binary files such as bitmap images and office-automation documents.)

Accordingly, AccuRev supports serial development through its exclusive file locking feature. Each workspace is in parallel-development mode (exclusive file locking disabled) or is in serial-development mode (exclusive file locking enabled). You can also set locks on individual elements.

The serial development model places more restrictions on users in the edit stage, but it eliminates the merge stage altogether. Here's the standard scenario, in which all the workspaces are in serial-development mode:

1.	A user starts working on a file by specifying it in a co (“checkout”) or anchor command. The file changes from being read-only to writable.

2.	AccuRev places an exclusive lock on the file. This prevents the file from being processed with co, anchor, or keep in other workspaces.

3.	The user can edit and keep any number of private versions of the file in his workspace. Then, the user promotes his most recently kept version to the backing stream. The exclusive file lock guarantees that no merge will be required before this promotion.

4.	After promote records the new version in the backing stream, things return to the initial state: AccuRev releases the exclusive lock, and the file returns to read-only status in the user’s workspace.

5.	A user in any workspace can now co or anchor the file, which starts the exclusive-file-locking cycle again.

For more details, see File Locking in Workspaces of the AccuRev CLI User’s Manual.

The Limited Effect of an Exclusive File Lock

Exclusive file locking does not freeze an element completely:

•	The lock applies only to the sub-hierarchy under a particular backing stream. It doesn't affect streams elsewhere in the hierarchy and the workspaces based on them.

•	The lock acquired through workspace-level or depot-level exclusive file locking applies only to workspaces in serial-development mode. Users in parallel-development-mode workspaces can make changes and promote the changes to the backing stream.

A lock placed on an individual element in a workspace applies to all sibling workspaces.

•	The lock doesn’t prevent the current version in the backing stream from being promoted to higher-level streams.

Exclusive file locking does not prevent any user from modifying any file with a text editor or IDE. AccuRev encourages users in serial-development-mode workspaces to “ask permission first”: it maintains files in a read-only state, and makes a file writable when a user executes a co or anchor command on it. But users can modify a file “without asking permission”, by changing the access mode (UNIX/Linux: chmod command, Windows: attrib command or Properties window) and then editing it. Such “unauthorized” changes can’t be sent to the AccuRev depot, though: the exclusive file lock disallows a co, anchor, or keep.

Anchor-Required Workspaces

AccuRev also offers a less-restrictive variant of exclusive file locking. Anchor-required workspaces allow parallel development, with multiple users modifying the same file at the same time (in their own workspaces). But as in the exclusive file locking environment, files are read-only by default, and must be anchored (“checked out”) before they can be modified.