[p4] Is Sync -f trouble?

Jeff Grills jgrills at junctionpoint.com
Wed Nov 1 08:07:42 PST 2006

Even if you can't trust your build system to clean up after itself, that's
still no reason to remove everything and start from scratch.  Use "p4 diff"
to efficiently detect the differences and resync just those files and delete
the extra files as I explained in the email to which you replied.  It might
not be that big of an issue in a small depot when a fresh sync only takes a
few minutes, but with over 120,000 files and 4gb of data it becomes
imperative to do something smarter.

And if you still wanted to remove everything and re-sync against all the
better advice presented in the thread, I'd advise flushing to #none and
using your OS commands to remove the directory tree (rm -rf or whatever),
and then syncing to #head.  That can save some valuable time as well.


> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Rich Ireland
> Sent: Wednesday, November 01, 2006 12:10 AM
> To: perforce-user at perforce.com
> Subject: Re: [p4] Is Sync -f trouble?
> This seems to be a "belt and suspenders" situation.  You 
> don't trust your automated build system to clean up after 
> itself and therefore you must delete the entire workspace manually.
> If you really can't trust your build, then a sync to #none 
> followed by a remove of the offending directory structure 
> followed by a sync to #head is all you need.  The -f is gratuitous.
> Jeff Grills wrote:
> > There are times to use "p4 sync -f", otherwise it wouldn't be an 
> > available option.  However, I'd agree with support that 
> using that in 
> > an automated script to get a clean build is a mistake and can cause 
> > significant performance issues with your server.  All you 
> really need 
> > to do is to verify that your files are identical to the 
> server's copy 
> > and that no extra files exist.  First sync to head, and 
> then use "p4 
> > diff -sl //..." to compare the files on your client with 
> the server.  
> > p4 will read the files on the client and compute their md5 
> signatures 
> > and compare them with the server's md5 signature, which is server 
> > stored in the metadata so the server doesn't even have to read its 
> > copy of the file.  Very little work is done by the server and very 
> > little data is transferred over the wire, so it's hard to get much 
> > better than this.  If any files are different, then you can 
> use a "p4 
> > sync -f" to bring those specific files back into sync.  The only 
> > remaining thing to do is to remove all the files that the server 
> > didn't tell you about.  If your client mapping is 
> relatively obvious, 
> > you can probably post-process the diff's output into the 
> list of files that should exist, and then remove any others.
> > 
> > "p4 integrate" is usually the command that I see hang 
> servers up for a 
> > while, although that's been getting better in recent versions of p4.
> > 
> > j
> > 
> > -----Original Message-----
> > From: perforce-user-bounces at perforce.com
> > [mailto:perforce-user-bounces at perforce.com] On Behalf Of Venters, 
> > Cheryl
> > Sent: Tuesday, October 31, 2006 10:49 PM
> > To: perforce-user at perforce.com
> > Subject: [p4] Is Sync -f trouble?
> > 
> > 
> > We're still having terrible problems with P4 performance. When I 
> > talked to Perforce today, the person I talked to told me we should 
> > never be running p4 sync -f. All of our automated scripts run the 
> > sequence sync #none, delete the build directory, sync -f. 
> That has been our policy for a clean build.
> > Does anybody have input on this? And, are there p4 commands 
> that have 
> > a greater potential for hanging the server?
> > 
> >  
> > 
> > Thanks.
> > 
> > Cheryl
> --
> Rich Ireland
> mailto:r.ireland at computer.org
> Embedded & Real Time Engineering
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user

More information about the perforce-user mailing list