[p4] p4 verify question

[G Barthelemy]

On Mon, Oct 6, 2008 at 11:34 PM, Tony Sweeney <sweeney at addr.com> wrote:
>> ... to verify the first and head revisions of all files. This leads me
>> to believe that it's a good idea to run a plain p4 verify -q after the
>> -u -q, but is this (only #1 and #head) significantly faster than running
>> it on //...?
>
> I benchmarked this while working at a large computer games company and
> it turned out to be significantly slower to run the two separate #1,#1
> #head,#head passes versus a single pass against //... -- approximately 2
> x 3 hours v/s 1 x 4ish hours, from what I recall.  However, this may be
> a pathological case due to the nature of the files stored in Perforce;


And if whole sections of your depot are made of files that haven't
changed, doing this will recompute the MD5 checksum twice for the same
revisions. When those are large binaries, then it becomes significant.

What about a daily p4 verify that only checks the new file revisions
since the last verify was run (based on a "p4 changes" command, maybe
even using a counter to store the last changelist that was verified,
then parsing through individual "p4 describe -s" commands, etc...),
filtering out deletes, etc... If a revision greater than 1 is found,
then check the new revision as well as its predecessor, even if that
was checked in a previous run (as both would have been newly written
to disk because of the reverse delta storage of text files) ? Then
once in a while, run a full check out of hours (for peace of mind).

There are also time gains to be made if you have the spare CPU by
parallelising multiple instances of p4 verify (that point was made
recently on the list).

Let us know how many kWh you end up saving :-)

Cheers,
Guillaume