Each element has a status in each workspace or stream in which it appears. Keep in mind that an element can (and usually does) have different status in different workspaces/streams.
|
•
|
(elink) — the element is an element link.
|
|
•
|
|
•
|
(missing-target) — For an element link, the target element is not present in the workspace or stream. This can occur if the target element is removed from the workspace tree by an operating system command. It can also result from an incl –b or excl command. For a symbolic link, there is no object at the target pathname.
|
|
•
|
(modified-target) — For an element link, the target element has been modified (either a content change or a namespace change) in the workspace or stream.
|
|
•
|
(defunct-target) — For an element link, the target element has (defunct) status in this workspace or stream.
|
|
•
|
(nonexistent-target) — For an element link, the target element does not appear at all in this stream or workspace. This occurs when the target element is defunct’ed then promote’d to the parent stream.
|
|
•
|
(corrupted) — For an element link in a workspace, AccuRev and the operating system disagree on the link target. That is, the target element recorded in the AccuRev repository differs from the target in the operating system’s instantiation of the link in the workspace tree. This can occur if you modify or replace a link using operating system commands instead of AccuRev commands.
|
A cross-linked element (see (xlinked) below) gets (corrupted) status if AccuRev does not overwrite the element during execution of the Include from Stream command, because the element has (modified) or (kept) status in the workspace. This should not occur during normal operation.
|
•
|
(defunct) — the element has been marked for removal from the workspace stream with the defunct command. The element has already been removed from the workspace tree (local disk storage); it gets removed from the workspace stream (in the depot) when you promote the element to the backing stream.
|
|
•
|
(external) — the file or directory has not been placed under version control. (It’s in the workspace tree, but not in the workspace stream.) See Specifying Ignore Patterns for External Objects in AccuRev Technical Notes.
|
|
•
|
(ignored) — the external file or directory matches a pattern specified in either the .acignore file, or the --ignore option (for the add, files, and stat commands). See Specifying Ignore Patterns for External Objects in AccuRev Technical Notes.
|
|
•
|
(excluded) — the element does not appear in the workspace because it has been excluded, using the Include/Exclude facility. For file elements, it’s more likely that the exclusion was explicitly set on the directory in which the file resides, or in a higher-level directory that includes the file. See the incl, excl, and incldo reference pages.
|
|
•
|
(xlinked) — this version of the element appears in the workspace or stream by virtue of a cross-link (incl –b command) — either on the element itself or on its parent directory or a higher-level directory.
|
|
•
|
(missing) — the workspace “should” include a version of this element, but doesn’t. This occurs most often when you delete version-controlled files from the workspace tree using operating system commands. If an operation causes the target of an element link to be removed from a workspace, AccuRev removes the element link, also, causing it to have (missing) status.
|
|
•
|
(twin) — the element is one of multiple elements in the workspace that exist at the same pathname. At most one of these elements can be accessed through the pathname; the other(s) can be accessed through their unique element-IDs. See Version Control of Namespace-Related Changes in AccuRev Technical Notes.
|
|
•
|
(stranded) — the element is active in the workspace, but cannot be accessed through the file system. This can occur in several situations:
|
|
•
|
|
•
|
(modified) — the file has been modified in the workspace since the most recent update or keep. See Optimized Search for Modified Files.
|
|
•
|
(kept) — a new version of the element has been created with keep, move, defunct, or undefunct, and the file has not subsequently been modified, promote’d to the backing stream, or purge’d.
|
|
•
|
(member) — the element is “active” in the workspace (is in the workspace stream’s default group). The commands that create a new version, listed above, also make the element active. So do the commands merge and revert, which invoke the keep command. And so do the commands anchor and co, which make an element active by creating a virtual version in the workspace.
|
|
•
|
(backed) — the version in the workspace stream is the same as the version in the backing stream. And you have not changed the element since the last time you promote’d or purge’d it, or since the most recent update of your workspace.
|
|
•
|
(stale) — the element needs to be updated, because the version in the backing stream has changed since the workspace’s latest update. And since you have not changed the element in your workspace, it can be safely updated.
|
|
•
|
(overlap) — the element has changed both in the backing stream and in your workspace. This indicates that a merge is required before you can promote your changes to the backing stream. Prior to AccuRev 4.6, “underlap” files were considered to have “overlap” status.
|
|
•
|
(underlap) — similar to overlap: the element has changed both in the backing stream and in your workspace, but the changes in your workspace have already been promoted to the backing stream. (More precisely, your version is an ancestor of the backing stream’s version.) In many cases, no promote is required; you can just purge the changes from your workspace, restoring the version that was in the backing stream at the time of the workspace’s most recent update. Prior to AccuRev 4.6, “underlap” files were considered to have “overlap” status.
|
In a new workspace, the status of every element is backed. This means that the version in your workspace is identical to the version in the backing stream. The following sections describe the other statuses.
As soon as you make a change to an element, its status changes to modified. The element's status stays “modified” until you do a keep or purge on it. If the element is purged, its status reverts to “backed”.
When you add a new element or keep an existing element, its status becomes kept. The element stays “kept” until you do a purge or promote on it (which changes the status to “backed”), or make a change to it (which changes its status to “modified”).
Note: the examples in this section were taken from the Version Browser in the AccuRev GUI to better illustrate the circumstances that lead to (overlap) and (underlap) statuses.
Prior to AccuRev 4.6, (overlap) status was defined as follows:
Version W, in a workspace or stream, has (overlap) status if version P in the parent stream is not an ancestor of version W.
Version P is not an ancestor of version W, but Version W is an ancestor of version P.
That is, the changes in the workspace or stream’s version already appear in the parent stream. This is not considered to be an (overlap), but a new status, called (underlap).
The example below illustrates a common (underlap) scenario: john brings an old version, brass32_dvt_mary/12, of the element into his workspace, using the co (GUI: Send to Workspace) command; this old version is an ancestor of the version currently in the backing stream of john’s workspace.
