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 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, through its exclusive file locking feature, and  parallel 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:

•	It is maintained in a read-only state in your workspace tree.

•	If the element is active in a sibling workspace, you cannot make the element active in your workspace.

•

If the element is not active in a sibling workspace, you can make it active in your workspace with the Send to Workspace or Anchor command. This makes the file in your workspace tree writable. (You must do this before you can use Keep to create a new version.) You can also make an element active with Revert, Rename, Defunct, Paste (after a Copy), or the CLI command undefunct.

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:

•	A promote command sends your private changes to an element from your workspace stream to the backing stream.

•	A purge command discards your private changes to an element.

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:

•	The lock applies only within the scope of a particular backing stream. It doesn't affect other backing streams 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 file element in a workspace applies to all sibling workspaces, but not to other 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: 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:

•	You can make a file element active with the Send to Workspace or Anchor command. This makes the file writable. You must do this before you can use Keep to create a new version.

•	You can also make an element active with Revert, Rename, Defunct, Paste (after a Copy), or the CLI command undefunct.