Sun WorkShop TeamWare: User's Guide: 7 - TeamWare Configuring Workspace

# TeamWare Configuring Workspace | # 7 |

As discussed in Chapter 3, "Introduction to TeamWare Configuring", the workspace forms the basis of the Configuring system. The workspace provides isolation in which you (a developer) work in parallel with other developers programming in other workspaces. For an introduction to the Configuring workspace, refer to "Workspace" on page 20 of this manual.

This chapter discusses specific aspects of workspaces and the Configuring commands you use to configure, create, manipulate, and administer them, and contains the following sections:

The Workspace Metadata Directory | page 62
Creating a Workspace | page 64
Deleting a Workspace | page 64
Moving and Renaming a Workspace | page 65
Reparenting a Workspace | page 66
Controlling Access to Workspaces | page 71
How to Notify Users of Changes to Workspaces | page 75
Viewing Workspace Command History | page 78
Ensuring Consistency through Workspace Locking | page 80
Configuring Environment Variables | page 81

## The Workspace Metadata Directory

A Configuring workspace is a directory hierarchy that contains a directory named `Codemgr_wsdata` in its root directory. the Configuring program stores data (metadata) about that workspace in `Codemgr_wsdata`. Configuring commands use the presence or absence of this directory to determine whether a directory is a workspace.

All data stored in the `Codemgr_wsdata` directory is contained in ASCII text files that can be edited by users. Table 7-1 briefly describes each of the files and directories contained in the metadata directory. Information regarding the format of these files is available in the `man(4)` page for each file.

#### Table 7-1 Contents of the `Codemgr_wsdata` Metadata Directory

File/Dir Name | Description
`access_control` | The `access_control` file contains information that controls which users are allowed to execute Configuring transactions and commands for a given a workspace. When workspaces are created, a default access control file is also created. See Section , "Controlling Access to Workspaces," on page 71.
`args` | The `args` file is maintained by the Configuring Bringover and Putback transaction commands and contains a list of file, directory, and FLP arguments. Initially, the `args` file contains the arguments specified when the workspace was created. If you explicitly specify arguments during subsequent Bringover or Putback transactions, the commands determine if the new arguments are more encompassing than the arguments already in the `args` file; if they are, the new arguments replace the old.
`backup/` | The `backup` directory is used to store information that Configuring uses to "undo" a Bringover or Putback transaction. See Section , "Reversing Bringover and Putback Transactions with Undo," on page 105.
`children` | The `children` file contains a list of the workspace's child workspaces. The names of child workspaces are entered into the workspace's `children` file during the Bringover Create transaction. Configuring consults this file to obtain the list of child workspaces. When you delete, move, or reparent a workspace, Configuring updates the `children` file in its parent.
`conflicts` | The `conflicts` file contains a list of files in that workspace that are currently in conflict. See Chapter 9, "Resolving Conflicts," for more information about conflicts and how to resolve them.
`history` | The `history` file is a historical log of transactions and updated files that affect a workspace. See "Viewing Workspace Command History" on page 78 for more information.
`locks` | To assure consistency, Configuring locks workspaces during Bringover, Putback and Undo transactions. Locks are recorded in the `locks` file in each workspace; Configuring consults that file before acting in a workspace. See "Ensuring Consistency through Workspace Locking" on page 80.
`nametable` | The `nametable` file contains a table of SCCS file names (path names relative to that workspace) and a unique number represented as four 32-bit hexadecimal words. Each entry in the table is terminated by a newline character. The `nametable` file is used by Configuring during Bringover and Putback to accelerate the processing of files that have been renamed. If this file is not available, Configuring rebuilds it automatically during the next Putback or Bringover transaction. See "Renaming, Moving, or Deleting Files" on page 108.
`notification` | The `notification` file is edited by users to register notification requests. This facility permits Configuring to detect events that involve that workspace and to send electronic mail messages in response to the event. See Section , "How to Notify Users of Changes to Workspaces," on page 75.
`parent` | The `parent` file contains the path name of the workspace's parent workspace and is created by the Bringover Create transaction, or by the Reparent command if the workspace was originally created with the Create Workspace command (and thus had no parent). Configuring consults this file to determine a workspace's parent. When you delete, move, or reparent a workspace, Configuring updates the `parent` file in its children.
`putback.cmt` | The `putback.cmt` file is a cache of the text of the comment from the last blocked Putback transaction. When a Putback transaction is blocked, the comment is discarded. Configuring caches the comment in `putback.cmt` so that you can retrieve the original text when you reexecute the transaction.

## Creating a Workspace

You can create a workspace in one of two ways:

- Explicitly by means of the Create Workspace item in the File menu on the main Configuring window

- Implicitly by using the Bringover Create transaction to copy files into a nonexistent child workspace, in which case the child workspace is created and then populated with the files specified as part of the transaction

### Using Workspace Create

The Workspace Create item in the Configuring File menu is used to create new workspaces. Type the name of the new workspace's root (top-level) directory in the Workspace Directory text field and click on the Create Workspace button.

If the workspace you are creating already exists as a directory hierarchy, Configuring converts it to a workspace by simply adding the `Codemgr_wsdata` directory in the root directory and displaying its icon in the Workspace Graph Pane.

If the directory does not already exist, Configuring creates both the root directory and the `Codemgr_wsdata` directory.

### Using the Bringover Create Transaction

Use the Bringover Create transaction (on the Transactions menu) to copy files from a parent workspace to a nonexistent child workspace; the child is automatically created as part of the transaction. See "Creating a New Child Workspace (Bringover Create)" on page 90 for details.

The online Help provides further assistance in Creating New Workspaces. To access the help, choose Help Help Contents Starting a Project.

## Deleting a Workspace

You delete workspaces by selecting their icons in the Workspace Graph Pane and then invoking the Delete item from the Configuring Edit menu.

Two menu items are provided that delete workspaces:

- Sources and Codemgr_wsdata Directory

  Recursively deletes the contents of the workspaces.

- Codemgr_wsdata Directory only

  Changes their status to nonworkspace directories by deleting only the `Codemgr_wsdata` directory and removing their icons from the Workspace Graph Pane.

In either of these cases Configuring automatically updates records in parent and child workspaces to reflect the deletion of the workspace.

When you choose the Sources and `Codemgr_wsdata` Directory command, you are prompted to confirm your decision.

## Moving and Renaming a Workspace

Since workspaces are directories, you move them by changing their path names. There are two ways that you can move/rename a workspace:

- By editing its name in the Workspace Graph pane

  Select the name field by moving the pointer over a portion of the text and click SELECT. This selects the text for editing. Use standard text editing to change the name; type Return to enter your changes. Click SELECT in an empty portion of the pane to deselect the text.

- By using the Rename command item from the Configuring Edit menu

  The path name of the selected workspace is changed to the name that you type in the New Workspace Name text field.

In addition to changing the workspace path name, both methods also update the appropriate data files in the parent and child workspaces to contain the new name. These data files are discussed in "The Workspace Metadata Directory" on page 62.

### A Note About Moving Workspaces

> Caution - Do not use the SunOS `mv` command to rename or move workspaces.

The Configuring Rename command updates files in the workspace's parent and children, as well as logging the event in the `Codemgr_wsdata/history` file.

If you inadvertently use the `mv` command to move/rename a workspace and discover that it has become "disconnected" from its parent and children, you can use the Rename command to reconnect it.

For example, if you used the `mv` command to rename a workspace from A to B:

  1. Use the Rename command to rename B to C.

    This causes Configuring to update the workspace's new name (C) in the parent and child workspaces. To save time, be sure to use a path name on the same device.

  2. Use the Rename command to change C back to B.

    Everything should be reconnected.

## Reparenting a Workspace

As discussed in Chapter 3, "Introduction to TeamWare Configuring," "Parent and Child Relationship" on page 22, the parent/child relationship is the thread that connects the workspace hierarchy. Configuring provides the means for you to change this relationship at your discretion.

This section discusses how you can explicitly change a workspace's parent. It is also possible for you to implicitly change a workspace parent "on the fly" (for the duration of a single command) by specifying the new parent's path name as part of a Bringover Update or Putback transaction. See the descriptions of the Bringover Update and Putback transactions in "Copying Files between Workspaces" on page 83 for more information.

The following sections describe:

- Two methods that you can use to change a workspace's parent
- Some reasons why you might want to change a workspace's parent
- An example of using the rename feature

### Two Ways to Reparent Workspaces

This section describes two completely equivalent ways to reparent workspaces.

#### Drag and Drop Workspace Icons

You can change a workspace's parent by selecting its icon in the Workspace Graph Pane, pressing and holding the SHIFT key, and dragging it on top of its new parent's icon. The display is automatically adjusted to reflect the new relationship.

> Note - You are prompted to confirm the change.

You may also "orphan" a workspace by selecting its icon, pressing SHIFT, and dragging it to an open area on the Workspace Graph. The workspace no longer has a parent: the display is automatically adjusted to reflect its new status.

#### The Parent Command

You can change a workspace's parent by selecting its icon in the Workspace Graph Pane and then choosing the Parent command item from the Edit menu. This activates the Parent pop-up window.

When the window is initially activated, the New Parent Workspace Directory text field contains the name of the current parent; edit that line so that it contains the name of the new parent file. Click SELECT on the Parent button. The Workspace Graph Pane is automatically adjusted to reflect the new relationship.

If you do not specify a parent workspace in the New Parent Workspace Directory text field, the workspace is orphaned--it has no parent. The Workspace Graph Pane is automatically adjusted to reflect its new status.

### Reasons to Change a Workspace's Parent

Reasons why you might want to permanently or temporarily change a workspace parent are as follows:

- To populate a new project hierarchy (new top-level workspace)

  You may be completing Release 1 of your product and see the need to begin work on Release 2. In this case you might:

- Create a new (empty) Release 2 workspace by means of the Create Workspace command item.
- Use either of the two methods described above to make the Release 2 workspace the new parent of the Release 1 workspace.
- Use the Putback transaction to copy files to the Release 2 workspace.
- Reparent the Release 1 workspace to its original parent.

- To move a feature into a new release

  If a feature intended for a particular release is not completed in time, the workspace in which the feature was being developed can be reparented to the following release's integration workspace. A similar use of reparenting is described in the example in the next section.

- To apply a bug fix to multiple releases.

  The workspace in which work was done to correct a bug is reparented from hierarchy to hierarchy; the Configuring Putback transaction is used to incorporate the changes into the new parent. An example of this use of reparenting is included in the next section.

- To reorganize workspace hierarchies

- You can add additional levels to the hierarchy.
- You can remove levels from the hierarchy (do not specify a new parent during reparenting).
- You can reorganize workspace branches within the project hierarchy.

- To adopt an orphan workspace if its `Codemgr_wsdata/parent` file is deleted

  If, for some reason a file is orphaned (for example, its parent is corrupted or its own `Codemgr_wsdata/parent` file deleted) you can use the reparenting feature to restore its parentage.

#### A Reparenting Example

Often a bug is fixed in a version of a product and a patch release is made to distribute the fixed code. The code that was fixed must usually be incorporated into the next release of the product as well. If the product is developed using Configuring, the patch can be incorporated relatively simply by means of reparenting.

In the following example, a patch is developed to fix a bug in Release 1.0 of a product. The patch must be incorporated into Release 2.0, which has begun development.

  1. The workspace in which the patch was developed (or the workspace from which it is released) is cloned by means of the Bringover Create transaction. The reason the workspace is cloned is that it will be altered by its interaction with its new parent (Bringover transaction to synchronize it with its new parent).

  2. Either of the two reparenting methods are used to change the cloned workspace's parent from `1.0patch` to `2.0`. (Figure 7-1

  )

##### Figure 7-1 Patch Workspace Reparented to New Release

  3. The workspace is then updated from its new parent, and any new work is brought over from `2.0`. (Figure 7-2A)

  4. The fixes made for the patch are merged in `patch` with the files from `2.0` and are put back into the `2.0` workspace where they are now available to workspace `2.0child`. (Figure 7-2B)

##### Figure 7-2 Files Brought Over, Merged, and Incorporated into the New Release

  5. Files are brought over to `2.0child`, and `patch` is deleted by means of the Delete Sources and Metadata item from the Edit menu. (Figure 7-3)

##### Figure 7-3 Patched Files Brought Over into `2.0child`; `patch` Deleted

For more detailed examples of reparenting, refer to Sun WorkShop TeamWare: Solutions Guide, in particular, workspace hierarchy strategies.

## Controlling Access to Workspaces

Configuring permits you to control the access that users have to your workspaces. Table 7-2 lists and describes the eight types of access over which you can exercise control.

#### Table 7-2 Operations Over Which You Have Access Control

Type of Access | Description
bringover-from | Controls which users may bring over files from this workspace
bringover-to | Controls which users may bring over files to this workspace
putback-from | Controls which users may put back files from this workspace
putback-to | Controls which users may put back files to this workspace
undo | Controls which users may "undo" commands executed in this workspace
workspace-delete | Controls which users may delete this workspace
workspace-move | Controls which users may move this workspace
workspace-reparent | Controls which users may reparent this workspace
workspace-reparent-to | Controls which users may reparent other workspaces to this workspace

Prior to taking any of the actions listed above, the Configuring program consults a file in the `Codemgr_wsdata` directory named `access_control` to determine whether the user taking the action has access permission to the workspace for that purpose. The `access_control` file is a text file that contains a list of the eight operations and corresponding values that stipulate who is permitted to perform those operations. The `access_control` file is automatically created at the time the workspace is created and is owned by the creator of the workspace.

To view and change access permissions, use the Options menu. Choose the Workspace item, then use the Category button to choose the Access Control pane of the Workspace Properties pop-up window (see "Viewing and Changing Access Control Values" on page 74).

Table 7-3 shows the default contents of `access_control` after you create a workspace:

#### Table 7-3 Default Access Control Permissions

Operation | Permissions
bringover-from |
bringover-to | creator
putback-from |
putback-to |
undo |
workspace-delete | creator
workspace-move | creator
workspace-reparent | creator
workspace-reparent-to |

> Note - Creator permission indicates that Creator's login name appears.

You can express which users have or do not have access to a workspace in a number of ways. Table 7-4 shows all of the value types you can specify to control access to your workspaces and what the entries mean.

#### Table 7-4 Workspace Access Control Values

Value | Meaning
@engineering | All users in the net group named`engineering` can execute this operation
-@engineering | No users from the net group named `engineering` can execute this operation. Note that "`-`" denotes negation.
@special -user2 @engineering | All users in the net groups `special` and `engineering` can execute the operation; user2 cannot (unless `user2` is in the `special` netgroup). "`-`" denotes negation.
user1 user2 | The users `user1` and `user2` can execute the operation.
"-" | No user can execute the operation.
creator | Only the user who created the workspace can execute the operation. Note that the creator's login name actually appears.
(no entry) | Any user may execute the operation.

> Note - If a user is listed as having both access permission and restriction, the first reference is used.

> Note - Performance may degrade when net groups are included in the access control file. The time required to look up group membership can add several seconds to the execution of a given operation.

### Viewing and Changing Access Control Values

| #### To view the access control status of a workspace, do the following:

  1. Select a workspace icon in the base window Workspace Graph pane.

  2. Choose the Workspace item from the Options button menu.

| #### To change the access control status of a workspace, do the following:

  1. Select a workspace icon in the base window Workspace Graph pane.

  2. Choose the Workspace item from the Options button menu.

  3. Use the SELECT mouse button to select an access line in the global Access Control list, then select the Edit button to activate the Access Control Edit pop-up.

    The operation you selected before clicking on the Edit button is automatically selected for you.

  4. Optionally, use the Operation menu in the Access Control Edit pop-up to select an operation type.

  5. Choose the type of permission you wish to allow:

  - None: No users have permission
  - All: All users have permission
  - Specify: Use the Permissions list to construct a list of users and
    netgroups that are to be granted or denied permission

  6. If you choose to specify individual and/or group permissions, construct your entry using:

  - The Name text field to enter the name of the user or netgroup
  - The Type setting to specify whether the entry is a user or a netgroup
  - The Access setting to specify whether the specified user/netgroup is granted or denied permission

  7. Select the Insert button to enter your entry into the Permissions list.

  8. Select the Apply button to enter your selection into the global Access Control list.

  9. In the Workspace Properties pop-up, select the Set Default button to write the changes to the `access_control` file.

## How to Notify Users of Changes to Workspaces

You can request Configuring to notify you (through an electronic mail message) when a variety of Configuring events occur in a workspace. Notification requests are entered in the file named `notification` in the `Codemgr_wsdata` directory.

A notification request consists of the following items:

- An address to which mail is sent.
- The event for which you want notification triggered.
- An optional list of directories and files whose changes of status trigger notification. The list is bracketed by BEGIN/END statements.

The following is an example of a `notification` file that contains three requests:

    chip@mach1 bringover-to
    BEGIN
    dir1/foo.cc
    dir2
    END
    biff@mach2 bringover-to putback-to
    BEGIN
    .
    END
    biff@mach2 workspace-move

In the first entry, the user `chip@mach1` requests to be notified when the file `dir1/foo.cc` and any file in the directory `dir2` (path names are relative to the workspace root directory) are brought over to the workspace.

> Note - File and directory entries for each event are bracketed by BEGIN/END statements. An empty list, a missing list, or a list that consists of only the "." character indicate that all files and directories in the workspace are registered for notification.

In the second entry, user `biff@mach2` requests to be notified when any file in the workspace is brought over to, or put back to, the workspace. The "." character represents all files in the workspace.

In the third entry, `biff@mach2` requests to be notified if the workspace is moved. Events that involve entire workspaces (delete, move, reparent) do not accept directory/file lists.

Table 7-5 lists the events for which you can register notification requests:

#### Table 7-5 Notification Events

Event Name | Description
bringover-from | Send mail whenever files are brought over from the workspace in which the notification file is located.
bringover-to | Send mail whenever files are brought over to the workspace in which the notification file is located.
putback-from | Send mail whenever files are put back from the workspace in which the notification file is located.
putback-to | Send mail whenever files are put back to the workspace in which the notification file is located.
undo | Send mail whenever a transaction is "undone" in the workspace in which the notification file is located.
workspace-delete | Send mail if the workspace in which the notification file is located is deleted.
workspace-move | Send mail if the workspace in which the notification file is located is moved.
workspace-reparent | Send mail if the workspace in which the notification file is reparented.
workspace-reparent-to | Send mail if the workspace becomes the new parent of an existing workspace.

### Viewing and Changing Notification Entries

To view and change notification entries, select a workspace icon in the Workspace Graph pane and choose the Workspace item from the base window Options menu. Use the Category menu to choose the Notification pane. The requests contained in the `notification` file described on the previous page will be similar to those displayed in the Workspace Properties pop-up.

Use the items in the Edit menu to modify, create and delete notification entries. Choosing the Entry and Create menu items activates the Notification Edit pop-up.

To create a new request, choose (with no items selected) the Create item in the Edit menu. The Notifications Edit pop-up is activated--use this window to specify the following request information:

- The mail address to which notification mail is sent

- The event about which notification mail is sent

- The files the notification event applies to:

- Any file in the workspace (All)

- Specific directories and/or files (Specify). If you choose to specify files/directories, create the list of directories and files in the Files text pane. To create the list, activate the Add Files chooser by clicking on the Add files to List button. Delete files from the list using the Delete button.

Modify an existing entry, by selecting it in the Notification pane of the Workspace Properties pop-up and choosing the Entry item from the Edit menu. Use the Notification Edit pop-up to modify the entry.

Apply changes to the Notification Edit pop-up changes to the global Notification list, by clicking on the Apply button.

Apply changes to the `notifications` file, by clicking on the Set Default button in the Workspace Properties pop-up.

### Notes About Registering Notification Events

- The following events involve entire workspaces and thus do not require a directory/file list:

- workspace-delete
- workspace-move
- workspace-reparent
- workspace-reparent-to

- When a directory is specified in the list, all files hierarchically beneath it are automatically registered.

- The mail address can be any valid mail address, including aliases.

## Viewing Workspace Command History

Configuring commands are logged in the text file `Codemgr_wsdata/history`. Commands that affect a single workspace are logged only in that workspace; interworkspace transactions are logged in both the source and destination workspaces.

> Note - Although command entries are logged in both the source and destination workspaces, the list of changed files is entered only in the destination directory.

You can view the contents of this file to track or reconstruct changes that have been made to a workspace over time. Log entries consist of the underlying command-line entries and do not correspond to GUI menu item names. If you have any questions about the meaning or syntax of a command, refer to its `man` page for details. Table 7-6 lists the GUI operations and the corresponding CLI command that is entered in the history log.

#### Table 7-6 Corresponding GUI and CLI Commands

GUI Menu Item | Corresponding CLI Command
Create Workspace | `workspace` `create`
Rename | `workspace` `move`
Parent | `workspace` `parent`
Bringover Create | `bringover`
Bringover Update | `bringover`
Putback | `putback`
Undo | `ws_undo`
Resolve | `resolve`

> Note - In active workspaces, the `Codemgr_wsdata/history` file can grow very quickly. You may want to periodically prune the file to reduce its size.

The following portion of a history file was generated during a Bringover Update transaction; entries are described in Table 7-7. This entry is taken from the history file in the child; the corresponding entry in the parent is identical except that file status messages are not included.

    COMMAND bringover -w /home/sponge3/larryh/ws/man_pages -p

    	/home/sponge3/larryh/ws/manpages man trans/man
     update: man/Makefile
     update: man/man5/access_control.5
     create: man/man5/notification.5
     create: man/man1/codemgr.1
     rename from: man/man1/def.dir.flg.1
            to: man/man1/def.dir.flp.1
     update: man/man1/def.dir.flp.1
     create: man/man1/codemgrtool.1
     rename from: man/man1/fileresolve.1
            to: deleted_files/man/man1/fileresolve.1
     update children's name history:

    	deleted_files/man/man1/fileresolve.1
     rename from: man/man1/resolve_tty.1
             to: deleted_files/man/man1/resolve_tty.1
     update: deleted_files/man/man1/resolve_tty.1
     create: trans/man/man1/codemgr_acquire.1
     create: trans/man/man1/codemgr_prepare.1
    CWD /tmp_mnt/home/sponge3/larryh/temp
    RELEASE Beta 1.0
    HOST croak
    USER larryh
    PARENT_WORKSPACE  (/home/sponge3/larryh/ws/manpages)
    (sponge:/export/home/sponge3/larryh/ws/manpages)
    CHILD_WORKSPACE  (/home/sponge3/larryh/ws/man_pages)
    (sponge:/export/home/sponge3/larryh/ws/man_pages)
    START (Mon Jul 13 13:31:16 1992 PDT) (Mon Jul 13 20:31:16 1992 GMT)
    END (Mon Jul 13 13:32:08 1992 PDT) (Mon Jul 13 20:32:08 1992 GMT)
    STATUS 0

#### Table 7-7 History File Entry Descriptions

Entry | Description
COMMAND | Underlying command line issued for the operation. File status messages as displayed in the Transaction Output window are included only in the destination workspace history file.
CWD | Name of the current working directory when the command was executed.
RELEASE | Release number of the TeamWare software
HOST | Name of the system from which the command was executed.
USER | Login name of the user who executed the command.
PARENT_WORKSPACE | The path name of the parent workspace specified in two formats: host-specific and machine:pathname.
CHILD_WORKSPACE | The path name of the child workspace specified in two formats: host-specific and machine:pathname.
START | Time the command started execution, both locally and as measured by Greenwich Mean Time (GMT).
END | Time the command completed execution, both locally and as measured by Greenwich Mean Time (GMT).
STATUS | Exit status of the command: 0 = Normal completion, any other value indicates an error condition, warning, or other status.

## Ensuring Consistency through Workspace Locking

To assure consistency, the Configuring transactions--Bringover, Undo, and Putback--lock workspaces while they are working in them. These locks only affect Configuring transactions; other commands such as SCCS programs, are not affected. Locks are recorded in the `Codemgr_wsdata/locks` file in each workspace; the Configuring transaction commands consult that file before acting in a workspace. Two types of locks are used:

- A read-lock is used when a command must assure that a workspace does not change while it is examining its contents.

  Read-locks may be obtained concurrently by a number of commands; no Configuring command can write to the workspace while a read-lock is in force. A read-lock is obtained during a Bringover transaction in the parent when its files are examined in preparation for copying to the child, and during a Putback transaction in the child when its files are examined in preparation for copying to the parent.

- A write-lock is used when a command must assure that a workspace does not change while it is writing to it.

  Only one write-lock may be obtained for a workspace at any time. When a write-lock is in force, only the Configuring command that owns the lock can write to the workspace; other commands cannot obtain read-locks from the workspace. A write-lock is obtained during a Bringover transaction for the child when files are copied into it, and during a Putback transaction for the parent when files are copied into it.

If a Configuring command is unable to remove its lock after completion (for example, the system crashes), you must remove the lock yourself before Configuring commands will again be able to read and/or write in the workspace. You can use the Configuring GUI to view and delete active locks for a workspace, or you can edit the file directly.

To view and delete locks using the Configuring GUI, select a workspace icon from the Workspace Graph pane and choose the Workspace item from the main Props menu. Use the Category menu to choose the Locks pane.

To delete locks, select the line that contains the lock and click on the Delete button. To apply the deletion to the `locks` file, click on the Set Default button.

## Configuring Environment Variables

Configuring consults environment variables to direct some of its actions.

### The `CODEMGR_WS` Variable

If you do not explicitly specify a workspace as the focus of a Configuring command, many of the commands will consult the shell environment variable `CODEMGR_WS` to determine a default workspace as the focus of their action. If you have a workspace that is the primary focus of your work, use of the variable will allow you to execute the commands without specifying the workspace argument.

### The `CODEMGR_WSPATH` Variable

When it is started, Configuring automatically loads workspaces from directory path names specified in the `CODEMGR_WSPATH` variable.