Previous Table of Contents Index Next
Perforce 2012.1: Command Reference

p4 obliterate
Removes files and their history from the depot.
p4 [g-opts] obliterate [ -y -A -b -a -h ] file[revRange] ...
Use p4 obliterate with caution. This is the one of only two commands (along with the archive-purging option of p4 archive) in Perforce that actually remove file data.
The p4 obliterate command actually deletes the server's copy of a file's data, precluding any possibility of recovery. (By contrast, the p4 delete command merely marks the latest revision as deleted, but leaves earlier revisions intact in the depot.)
p4 obliterate can be used by Perforce administrators to permanently remove files from the depot. The file is removed from the Perforce server, along with all associated metadata, including references to the file in labels, the have list, and so on. After 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.
-y filespec
Perform the obliterate operation. Without this flag, p4 obliterate merely reports what it would do.
Restrict files in the argument range to those that are branched, and to files that are both the first revision and the head revision. This flag is useful for removing old branches (where only one revision exists) while preserving files that have been modified post-branch. You can greatly improve the performance of obliterate -b by using the -a flag with -b.
Skip the (potentially resource-intensive) search of db.archmap and do not remove the file from the server; only its metadata. Although the file is not removed from the server, you can use -a in conjunction with -b to speed up obliteration of branched files known to exist only as lazy copies.
Skip the search of db.have when looking for matching records to delete. The next time a client workspace that refers to these files is synced, any such files in the workspace will also also be removed from the workspace. (This is often the desired behavior, for example, in client workspaces on build machines.)
Usage Notes
Can File Arguments Use
Revision Specifier?
p4 obliterate is one 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.
A better way to save disk space is to relocate infrequently-accessed files onto lower-performance (or detachable) storage. Instead of obliterating files outright, consider using p4 archive and p4 restore in conjunction with an archive depot. With archive depots, file history is preserved and available to all users, and file contents may be moved to offline or near-line storage.
Obliterating files can alter the behavior of user commands. Syncing to an obliterated file does not remove the file from your client workspace, because the file is no longer part of any client workspace. Syncing to an obliterated revision of a file will either report that the file does not exist (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 [email protected] (binary) 'Fixed'
... #1 change 1231 add on 2001/04/12 by [email protected] (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 encounter difficulty.
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
Instead of obliterating files, you can save disk space on a local depot by archiving some of its revisions to an archive depot. History of changes to these files is preserved.
To restore archived revisions from an archive depot. (You cannot restore obliterated files, but you can restore archived files.)

Previous Table of Contents Index Next

Perforce 2012.1: Command Reference
Copyright 1999-2012 Perforce Software.