p4 verify

Synopsis

Syntax

Description

If invoked without arguments, p4 verify computes and displays the MD5 digest of each revision. If a revision is missing from the archive and therefore can't be reproduced, the revision's output line ends with MISSING! If the digests differ, the output line for the corrupt file ends with BAD!

Options

-q	Run quietly; verify the integrity of files for which MD5 digests have previously been generated, and only display output if there are errors.
-u	Store the filesize and MD5 digest of each file in the Perforce database if and only if no filesize and/or digest has been previously stored. Subsequent uses of p4 verify will compare the computed version against this stored version.
-v	Store the MD5 digest of each file in the Perforce database, even if there's already a digest stored for that file, overwriting the existing digest. (The -v flag is used only to update the saved digests of archive files which have been deliberately altered outside of Perforce control by a Perforce system administrator.)
-m maxRevs	Limit p4 verify to maxRevs revisions.
g-opts	See the Global Options section.

Usage Notes

Can File Arguments Use Revision Specifier?	Can File Arguments Use Revision Range?	Minimal Access Level Required
Yes	Yes	admin

• If p4 verify returns errors, contact Perforce technical support.

• It is good administrative practice to regularly verify the integrity of your depot files with p4 verify -q //...

For details, see the Perforce System Administrator's Guide.

• As of Release 2003.2, p4 verify -u is obsolescent, because Perforce Servers at Release 2003.2 and higher automatically generate and store MD5 checksums of files upon file submission. (You must still run p4 verify -u at least once following an upgrade to 2003.2, in order to generate signatures for any pre-2003.2 files for which signatures were not generated.)

• As of Release 2005.1, Perforce Servers track file length metadata on a per-revision basis. Newly submitted files have file length metadata added to the database automatically. (You must still run p4 verify -u at least once following an upgrade to 2005.1, in order to update file length metadata for any pre-2005.1 files for which file lengths were not stored.)

Administrators of very large sites (such as those with tens of millions of revisions) may encounter memory constraints immediately following an upgrade to 2005.1 if they attempt to update file length metadata for the entire repository at once. If this is the case, use the -m maxRevs flag to limit the number of revisions updated per command; p4 verify -u -m 1000000 //... limits file length metadata recomputation to a million files at a time, enabling an administrator to divide file length metadata recomputation over several calls to p4 verify.