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.

In this topic:

Workspace Structure

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:

src
    Red.java
    White.java
    Blue.java
test
    setup.pl
    testrun.pl
    analyze.pl
doc
    Colors.doc

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:

C:\dvt_work\src
C:\dvt_work\test
C:\dvt_work\doc

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:

H:\Projects\ColorWheel\derek\src
H:\Projects\ColorWheel\derek\test
H:\Projects\ColorWheel\derek\doc

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

accurev mkws ... -l C:\dvt_work ...

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

accurev chws ... -l H:\Projects\ColorWheel\derek ...

Back to top

Working with Files in a Workspace

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:

accurev stat -x -L \Projects\Colorwheel\derek\doc 

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

accurev stat Colors.doc

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

accurev stat ..\test\setup.pl

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

accurev stat C:\Projects\Colorwheel\derek\doc

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

accurev keep -c "bug fix" colors.doc ..\setup.pl

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

Depot-Relative Pathnames

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:

\.\src\Blue.java
\.\test\analyze.pl

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.

Selecting Files Using Filename Patterns and AccuRev Status

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.

• Filtering on AccuRev file status (for example –m, for “modified files”).

See Techniques for Selecting Elements.

Back to top

Working with Multiple Repositories

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:

accurev show -H pluto:6678 users

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.

Setting Up Workspaces on Multiple Repositories

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:

gizmo_dvt_john         /usr/john/gizmo_dvt          venus  5050
frammis_2.3maint_john  /usr/john/frammis_2.3_maint  pluto  6678

The format of the file is:

• workspace name, which must not contain SPACE characters

• 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.

• server machine name (or IP address)

• IP port number on which AccuRev server program listens

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.

Back to top

File Locking in Workspaces

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:

• It is maintained in the read-only state in your workspace tree when you are not actively working on it.

• 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.

• If the element is not active in any sibling workspace:

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

    UNIX/Linux: only the “user” write permission is enabled, not the “group” or “other” write permission. Your umask setting is ignored.

    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.

    • If an element is active in a sibling workspace, you will get a warning message. You can override this warning and anchor the file in your workspace by using anchor -O <filename>.

See Serial Development through Exclusive File Locking in the AccuRev Concepts Guide.

Back to top