[p4] p4 verify question

[Stephen Vance]

If you want to fix your MISSING errors given that you don't want to 
restore the original files, you can do one of two things. You can 
obliterate the revisions, or you can drop dummy gzip files (a compressed 
text file with contents like "Artificially replacing missing binaries" 
is a good candidate) in the right place in the depot tree and recompute 
their checksums.

Yes, you're hearing correctly.

Steve

Matt Janulewicz wrote:
> Excellent, thanks Stephen and Tony for the info. I suspected there was 
> some unnecessary verification going on but I wasn't sure. We are 
> running 2005.2 so I think the '-u' step is unnecessary. I've only been 
> here for a couple months but I do know that the Perforce data goes 
> back to 2002, so I suspect that this backup/verify job has been going 
> this way since before submits generated their own checksums.
>
> In looking at our logs it does seem like both our verify steps output 
> the same exact thing, which is a bunch of 'MISSING' statements. It's 
> probably no coincidence that all the files involved are .lib and .pdb 
> files and it looks like someone tried to delete them at some point. 
> They're all in two changelists. I honestly don't know what to make of 
> it. I can get a  revision graph of any of the files if I do a folder 
> history and click on a file in P4V but I haven't a clue where the .gz 
> archive of these files went to. I've checked about 10 of them and have 
> verified that the physical archive file is gone. I'm almost afraid to 
> ask where they went.
>
> Since the files themselves are missing, and apparently have been for 
> some time, I'm not apt to want to try to restore them. The files I 
> checked are all branches and only contain revision #1, and nothing has 
> been branched *from* them, either. They truly seem to be the lost boys 
> of one of our projects. Is there a way to purge these records so the 
> verify doesn't throw errors on them anymore? Would a simple obliterate 
> do?
>
> Other than that, I think I'm hearing that I can eliminate the 'p4 
> verify -u' step because our server is up to date enough to not need 
> it. Either way we'll be upgrading to 2008.1 in two weeks so I should 
> be good, for sure, after that.
>
> Thanks!
>
>
> -Matt
>
>
> Stephen Vance wrote:
>> Matt --
>>
>> Actually, the first command is more important for verification 
>> purposes and the second one shouldn't be necessary any longer.
>>
>> The first command is the one that will tell you if you have any 
>> corruption in your depot files. You should pay close attention to 
>> this output. It's your red flag to problems.
>>
>> The second one only fills in the checksum for any files that are 
>> missing it. A few years ago Perforce changed the server so that each 
>> submit automatically computes and stores the checksums, so this 
>> probably does a lot of scanning for no purpose. You'll only want to 
>> do this if you get "MISSING" messages from the first command, and you 
>> should figure out why you're getting those messages first.
>>
>> The comment about #1,#1 and #head,#head is an optimization that only 
>> has benefit for text files. As an artifact of the way text files are 
>> stored and reconstructed using the RCS reverse delta format, 
>> verifying the first revision implicitly verifies all other revisions 
>> against effectively all random errors (subject to an infinite monkeys 
>> kind of footnote). This approach will be significantly faster, but 
>> won't provide any verification of intermediate revisions of binary 
>> files. Unless you can cleanly segregate your text and binary files, I 
>> never implement this.
>>
>> If you need shorter processing times, break your verifies up into 
>> smaller chunks and run them in parallel. Or restore your backup 
>> against an offline server and run your verifies there to take it out 
>> of your production flow.
>>
>> Steve
>>
>> Matt Janulewicz wrote:
>>> Hello -
>>>
>>> I have inherited a nightly/weekly maintenance script that runs a 
>>> verify on a large set of data over the weekend. This sometimes takes 
>>> more than 12 hours (per day! It's split in half!) Upon actually 
>>> reading the script I see that it runs two commands one after the other:
>>>
>>> p4 verify -q //depot/...
>>> p4 verify -u -q //depot/...
>>>
>>> Is that first verify command really necessary? The output of it gets 
>>> dumped to a log file (which we eventually throw away after not 
>>> looking at it for a couple weeks) but other than that if we run the 
>>> '-u -q' part immediately after that, is it redundant? At other jobs 
>>> I've only ever run that second command on a weekly basis, I just 
>>> want to be sure I'm not missing something.
>>>
>>> In the 'p4 help' for verify it also mentions:
>>>
>>> p4 verify -q #1,#1
>>> p4 verify -q #head,#head
>>>
>>> ... 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 suspect it is but wonder if I'll 
>>> be missing anything, or leave my backups at risk, if I don't run it 
>>> on all revisions ...?
>>>
>>> Thanks!
>>>
>>>   
>>
>

-- 
Stephen Vance
www.vance.com