Workspaces and Depots

An AccuRev workspace is a directory hierarchy on your hard disk, containing files that are being managed by AccuRev. You can create any number of workspaces — different ones for different development projects.

Note: Usually, you can think of a workspace as simply containing a collection of files. Sometimes, though, it helps to adopt AccuRev’s viewpoint: each file is a version-controlled element; your workspace contains a copy of a certain version of that element.

The AccuRev repository is organized into a set of storage depots. Each depot has a directory hierarchy for physical file storage (containing a set of version-controlled files and directories), and a separate schema in the database for metadata storage. Depots cannot overlap and cannot be contained within one another.

Each workspace corresponds to a particular depot. If you need to work with the files in three different depots, you’ll need three different workspaces. Like the depots, the workspaces cannot overlap or be contained within one another.

Example: suppose a depot is structured like this:

Any number of users can create workspaces for themselves, to work with the files in this depot. On a Windows system, you might create a workspace at location C:\dvt_work. The depot’s subdirectories would be located in your workspace at:

You can create a workspace at any location you wish (as long as you have permission to access the disk storage). And you can move an existing workspace to another location — say, to a network drive with a larger capacity and a regular backup regimen. If you moved the workspace above to H:\Projects\ColorWheel\derek, then the three subdirectories would now be located at:

AccuRev needs to keep track of a workspace’s location. So you specify a pathname when you create the workspace:

And if you move the workspace, using ordinary operating system tools, you must inform AccuRev of the new location:

Your workspace is a private work area. The files in your workspace belong to you. You can edit them whenever you like — no special “check out” command is required. For example, to edit the Colors.doc document, you might start a word processor and specify the pathname H:\Projects\ColorWheel\derek\doc\Colors.doc.

When you specify files to an accurev command, however, you usually don’t use full pathnames. In general, you cd (“change directory”) to the workspace, then use relative pathnames to refer to files when issuing accurev commands.

Alternatively, you can specify a location within a workspace to the accurev command using the –L option, which is available from:

As usual, you can use simple filenames for files in the current directory:

And you can use relative pathnames for files in other directories in the same workspace:

You can even use absolute (full) pathnames to specify files:

You can mix different ways of specifying files on the command line:

But you cannot specify files from different workspaces in the same accurev command.

In addition, the accurev program recognizes a special kind of pathname, termed a depot-relative pathname. This is the pathname to an element from the top-level directory of the depot — or equivalently, from the top-level directory of the workspace. Examples:

The special prefix — \.\ for Windows, /./ for UNIX/Linux — that distinguishes a depot-relative pathname from an ordinary relative pathname. If your current directory is anywhere within a workspace, you can use a depot-relative pathname to refer to any element in the same workspace. If your current directory is not in the workspace, or you apply a command to a particular stream, using the –s option, you must specify elements using their depot-relative pathnames.

In many commands, you can specify the set of files to be processed using either or both of these mechanisms:

•

Filename patterns (for example, *.py). On Windows client machines, the accurev program performs pattern-matching itself. On UNIX/Linux windows machines, pattern-matching is performed by the operating system.

See Techniques for Selecting Elements.

It’s possible to have multiple AccuRev repositories active in your organization, each managed by its own AccuRev server process. For most accurev CLI commands, you can specify the AccuRev server to target on the command line, using the –H option:

Note that the –H option follows the command name — in this example, show — not the program name, accurev.

This mechanism bypasses the acclient.cnf file, though the file must still exist. It does not override a specification in the wspaces file, which is described below.

If the workspaces you’ve created on your client machine are not all associated with the same AccuRev server, then you might want to use a wspaces configuration file. This text file records the workspace-to-server association for each of your workspaces. Each user can have a wspaces file. It must be located under the user’s home directory, within the .accurev subdirectory.

The accurev program uses this file to decide which AccuRev server to use:

•

If the current working directory is within one of the workspace-root-directory locations listed in the wspaces file, the CLI command is directed to the associated server listed on the same line of the file.

•

Otherwise (including the case in which no wspaces file exists), the CLI command is directed to first server listed in the machine’s acclient.cnf file. This is the default behavior that we’ve mentioned in the sections above.

For example, here is a sample wspaces file recording workspaces associated with servers venus and pluto:

The format of the file is:

•

full pathname of workspace’s root directory, which must match the pathname listed by the accurev show wspaces command, and must not contain SPACE characters. The pathname always uses forward slashes ( / ), not backslashes ( \ ), even on Windows machines.

The last two fields must exactly match the server and port of an existing entry in the machine’s acclient.cnf file.

Note: If your site has a single AccuRev server (or if your workspaces are all associated with a single server), there is no need for a wspaces file: the default behavior directs each CLI command to the server listed in your machine’s acclient.cnf file.

Exclusive file locking (serial-development mode) can be implemented at the depot level, the workspace level, or the element level (keep –E, add –E). If exclusive file locking applies to an element:

•

If the element is active in a sibling workspace (having been processed with anchor, co, revert, keep, move, defunct, or undefunct), you cannot perform any of those commands on it in your 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.

•

You can make a file element active with the co or anchor command. This makes the file in your workspace tree writable.

•

You can use the keep, move, defunct, undefunct, or revert commands, which make an element active in the workspace in addition to their normal functions, without first using co or anchor.

An exclusive file lock on a file element is released when active development on the file ends in that workspace — that is, when you either promote or purge your changes.

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 co or anchor command. This makes the file writable.

•

You can make an element active with move, defunct, undefunct, or revert without having to first use co or anchor.