Previous Table of Contents Index Next
Perforce 2009.1: Command Reference



p4 obliterate
Synopsis
Removes files and their history from the depot.
Syntax
p4 [g-opts] obliterate [ -y ] file[revRange] ...
Warning
The p4 delete command marks the latest revision as deleted, but leaves the file information intact in the depot. As such, recovery from the server data is always possible.
In contrast, p4 obliterate deletes the file data itself, precluding any possibility of recovery.
Use p4 obliterate with caution. This is the only command in Perforce that actually removes file data.
Description
p4 obliterate can be used by Perforce administrators to permanently remove files from the depot. All information about the files is wiped out, including the files' revisions, the files' metadata, and any records in any labels or client workspace records that refer directly to those files. Once p4 obliterate completes, it appears to the server as if the affected file(s) had never existed. Copies of files in client workspaces are left untouched, but are no longer recognized as being under Perforce control.
p4 obliterate requires at least one file pattern as an argument. To actually perform the obliteration, the -y flag is required; without it, p4 obliterate merely reports what it would do without actually performing the obliteration.
If you specify a single revision (for instance, p4 obliterate file#3), only that revision of the file is obliterated. If you specify a revision range (for instance, p4 obliterate file#3,5), only the revisions in that range are obliterated.
Options
-y filespec
Perform the obliterate operation. Without this flag, p4 obliterate merely reports what it would do.
Usage Notes
Can File Arguments Use
Revision Specifier?
p4 obliterate is the correct way to reclaim disk space from files that are no longer required, or to clean up mistakes made by users who create file hierarchies in the wrong place. Do not use operating system commands (erase, rm, and their equivalents) to remove files from the Perforce server root by hand.
Obliterating files can alter the behavior of user commands. Syncing to an obliterated revision will remove the file from your client workspace, syncing to the head revision will either remove the file from your client workspace (if all revisions were obliterated), or provide you with the most recent non-obliterated revision of the file.
Obliterating files in revision ranges can also change the behavior of scripts, as revision numbers of files may "skip" obliterated revisions. For instance, the output of p4 filelog after obliterating revisions #2 and #3 might look like this:
... #4 change 1276 edit on 2001/04/18 by user@dev1 (binary) 'Fixed'
... #1 change 1231 add on 2001/04/12 by user@dev1 (binary) 'First try'
In this case, a developer using the #4 in the first line of the output to assume the existence of four change descriptions in the output of p4 filelog would be in trouble.
Examples
In this case, all files in directory dir and below would be subject to deletion with the -y option.
Obliterate file from the depot. All history and metadata for every revision of file are erased.
If #3 was the head revision, the new head revision is now #2 and the next revision will be revision #3.
If #3 was not the head revision, the head revision remains unchanged.
If #5 was the head revision, the new head revision is now #2, and the next revision will be #3.
If #5 was not the head revision, the head revision remains unchanged.
Related Commands
 


Previous Table of Contents Index Next

Perforce 2009.1: Command Reference
Copyright 1999-2009 Perforce Software.