[p4] Is there a way to audit a workspace?

Stephen Vance steve at vance.com
Mon Aug 17 16:41:14 PDT 2009

This is the most complete reply of the bunch so far.

A key piece of this is the specification of the expected change level in 
each of the commands. If you run these commands without specifying the 
expected change level, your results will change if something is 
successfully submitted between commands and you still won't have 


Richard Kistruck wrote:
> On 2009-08-17Mon, at 16:13, Roy Smith wrote:
>> We have a very large workspace where we keep our entire build 
>> toolchain (compilers, tools like perl and python, libraries, etc).  
>> Our build team wants to run "p4 sync -f" every day because they don't 
>> trust "p4 sync" (without the -f) to keep it up to date.  I'm trying 
>> to convince them that this is silly.  It's certainly very expensive, 
>> as it takes several hours to complete.  Worse, the act of doing a 
>> "sync -f" touches the files on disk, so any build that's currently 
>> running can be impacted as files change out from underneath it.
> ...and "sync -f" is not sufficient anyway!  (See below).
>> Is there some way to have p4 audit the files on disk and confirm that 
>> what's there is what's supposed to be there, without actually 
>> deleting and re-creating every file?
> As far as I know, the five ways a file can differ from what it 'should 
> be' are:
> 1. The local file is open for modification.
> 2. The local file is sync'd to the wrong revision.
> 3. The local file is not there -- it has been deleted.
> 4. The local file is there, unopened, but it has nonetheless been 
> 'edited' (corrupted).
> 5. The local file is extraneous, and should not be there.
> The commands to check for these five, in sequence, are:
> 1.  p4 opened ...
> 2.  p4 sync -n ... at NNN
> 3.  p4 diff -t -sd ... at NNN
> 4.  p4 diff -t -se ... at NNN
> 5.  find . -type f -print | p4 -x - add -n | grep " - opened for add$"
> (Where "@NNN" is the changelist number you want your local files to 
> match).
> If your local files do indeed match ... at NNN, then the results you will 
> see are:
> 1.  "... - file(s) not opened on this client."
> 2.  "... - file(s) up-to-date."
> 3, 4, 5: no output.
> This is the procedure I use.  I hope it is correct; corrections, 
> improvements, or pointers to an extant TechNote very much welcomed :-)
> Richard Kistruck
> Ravenbrook Limited
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

Stephen Vance

More information about the perforce-user mailing list