[p4] p4 verify question

[Jeff A. Bowles]

My favorite was a conversion / upgrade a few months back, and one check-sum
file was wrong (when compared to its stored checksum).
The contents of the gzip'ed content file read: "this file was removed by
thus-and-such to save disk space. Blame thus-and-such if it fails and breaks
everything." (Dated a couple of years before, in a string included with the
compressed text.)

We laughed, said a quietly mumbled thanks to the guy who left tracks behind,
and made a note to ourselves. He could've recomputed the checksum, sure, but
he still did just about all of the rest "right".

  -Jeff Bowles


On Tue, Oct 7, 2008 at 1:31 AM, Stephen Vance <steve at vance.com> wrote:

> 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
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com