The defunct command removes elements from active use in your workspace. That is, for each element you specify, it:
Since the file is gone, operating system commands such as ls (UNIX/Linux) or
dir (Windows) won’t find a defunct element:
But the stat and
files commands will see the defunct element in your working stream:
defunct does not remove an element from the depot altogether. (In fact,
no operation removes an element — that would violate AccuRev’s
TimeSafe property.) And
defunct does not make an element disappear for all users.
defunct just removes an element from a particular workspace. The element remains visible in other streams and workspaces — at least for the time being (see
Propagating Deactivation with the ‘promote’ command below).
If you defunct the target of an element link, the link is automatically removed from your workspace. The indicators (missing) and
(defunct-target) are added to the link’s status. When you promote the defunct target element to the backing stream, the link’s status changes from
(defunct-target) to
(nonexistent-target).
If you defunct the target of a symbolic link, the link is not removed from your workspace. The indicator
(missing-target) is added to the link’s status.
If any of the elements you specify is a directory, defunct works recursively: it removes the directory itself and elements under that directory. Only the specified directory itself becomes
(defunct); the files and directories below it are simply removed from the workspace tree, but do not become
(defunct) in the workspace stream.
A stranded file or directory is not removed from your workspace tree. But the
stat or
files command lists the object as
(external), since the workspace stream no longer has a valid pathname to the object. See
Elements under a defunct parent of the
AccuRev Technical Notes.
CAUTION: In all cases of defuncting a directory, a file below the defuncted directory that you have edited — but never preserved with
keep — will be removed from the workspace tree. (Such files are not officially “active” in the workspace.) This removes data for which there might be no other copy.
For example, suppose you wish to defunct the directory subtree starting at dir01. But before doing so, you first defunct the lower-level file
dir01/sub02/file03.txt, and also the lower-level directory
dir01/sub06. At this point, you have two element with
(defunct) status:
If you then proceed to defunct directory dir01, those two elements will become stranded — the previous
defunct commands made them “active” in the workspace, but the last
defunct command caused them to have no pathname in the workspace:
It would have been better not to work at all with the elements lower in the directory tree — simply defunct the highest-level element, dir01. This removes
dir01/sub02/file03.txt and
dir01/sub06 from the workspace (presumably, along with many other elements), but does not cause them to become stranded.
After defuncting an element, you use
promote to propagate its deactivation to your workspace’s backing stream. (This parallels creating a new version of an element with
keep, then propagating the version to the backing stream with
promote.) After promotion, even the
stat and
files commands won’t see the defunct element.
To reactivate a defunct element, use the undefunct command. You can do this either before or after you promote the deactivation to the backing stream. (For special cases, see the
undefunct reference page.)
In the future, an element that you have defuncted will be removed from all streams to which the change is promoted. When other people update their workspaces (or reference trees) that are backed by those streams, the element will be removed.
Defunct the entire directory tree named alpha_project, located at the top level of the depot: