File Locking

Serial Development and. Parallel Development

The Limited Effect of an Exclusive File Lock

Anchor-Required Workspaces

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 though merging is largely automated. Some files cannot be merged, because they are in binary format. (The merge algorithm handles text files only, not binary files such as bitmap images and office-automation documents.)

Serial Development and Parallel Development

Accordingly, AccuRev supports both serial development The practice of ensuring that multiple users do not work concurrently on the same version-controlled file. See parallel development., through its exclusive file locking feature, and  parallel development ('concurrent development') The practice of having two or more users concurrently work on the same project — modifying the same version-controlled elements. See serial development.. Exclusive file locking can be implemented at the depot level, the workspace level, or the element level (when you place the file under version control or when you create a new version)

The serial development model places more restrictions on users in the edit stage, but it eliminates the merge stage altogether. [example]

Here's a 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 Send to Workspace ("checkout") or Anchor command. The file changes from being read-only to writable.

  2. AccuRev places an exclusive file lock on the file. This prevents the file from being processed with Send to Workspace, 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 Promote's 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 file lock, and the file returns to read-only status in the user's workspace.

  5. A user in any workspace can now Send to Workspace or Anchor the file, which starts the exclusive-file-locking cycle again.

If exclusive file locking applies to a file element, and the element is not currently active in any sibling workspace: [note In this context, workspaces are considered siblings if they promote to the same stream. If the stream hierarchy includes pass-through streams, workspaces can be siblings even if they have different parents.]

An exclusive file lock on a file element is released when active development on the file ends in that workspace:

Either way, the workspace returns to using a backing-stream version of the element.

The Limited Effect of an Exclusive File Lock

Exclusive file locking does not freeze an element completely:

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: 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 Send to Workspace, 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). In an anchor-required workspace, all elements are maintained in a read-only state when you are not actively working on them. Using such a workspace is similar to working with exclusive file locking, except that you are not constrained by elements' activity in sibling workspaces: