p4 verify
Synopsis
Verify that the Perforce versioning service's archives are intact.
Syntax
p4 [g-opts
] verify [-t | -u | -v | -z] [-m max
] [-q -s -X] [-b batch
] file
[revRange
] …
p4 [g-opts
] verify -U unloadfile
…
Description
p4 verify reports the revision specific information and an MD5 digest (fingerprint) of the revision's contents.
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!
In replicated environments, p4 verify -t reports
BAD!
or MISSING!
files with
(transfer scheduled)
at the end of the line.
Options
|
By default, p4 verify processes files in
batches of 10,000 files at a time. You can change this batch
size with the |
|
Limit p4 verify to
|
|
Run quietly; verify the integrity of files for which MD5 digests have previously been generated, and only display output if there are errors. |
|
Verify file size as well as digest. The |
|
When run on a replica, p4 verify -t causes the replica to schedule a transfer of the contents of any damaged or missing revisions.
The |
|
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. |
|
Verify files in the unload depot. See p4 unload for details. |
|
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
The |
|
Skip files of filetype |
|
Skip revisions that have already been computed in the current
pass; this option speeds verifications in the cases of revisions
which exist via lazy copies. This option cannot be used with the
|
|
See “Global Options”. |
Usage Notes
Can File Arguments Use Revision Specifier? |
Can File Arguments Use Revision Range? |
Minimal Access Level Required |
---|---|---|
Yes |
Yes |
|
-
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 -qz //...
For details, see the Perforce Server Administrator's Guide: Fundamentals.
-
As of Release 2005.1, Perforce tracks 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
option 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.maxRevs