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.
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.
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:
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:
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.
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.
•
|
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”).
|
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:
•
|
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
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.
|
•
|
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.
|
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: