[p4] p4 sync quirk

Ivey, William william_ivey at bmc.com
Mon Aug 23 14:52:52 PDT 2010

Correction: The last workaround down there with the compound revision
specifiers does not work - it only seemed to because of the way my
workspace was synced. (Support didn't catch this either, looking at it.)

The only reliable sync is separate sync commands when the paths overlap.


-----Original Message-----
From: perforce-user-bounces at perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of Ivey, William
Sent: Wednesday, August 18, 2010 10:02 AM

Support said this was expected behavior, but I didn't see it documented
in any obvious way in the version of the command reference for our
server, so I thought I'd post it here to save others some headaches.
(They said there was a request to change the behavior, so our users
weren't the first to find it.)

Let's say you have two changes, 5 and 8, on the same path and 8 adds
a file. You decide you want your workspace to include all changes up to
5, plus 8 by itself. So, in a clean workspace, you do this:

p4 sync //depot/... at 5 //depot/...@=8

That works. But if you run the identical command a second time, the file
added by change 8 disappears even though the command reports that
files are up to date. Run it a third time and the file comes back. A fourth
time and it's gone again, etc. The same thing will happen if similar file
patterns are fed in from a file via the -x <file> option.

Presumably as an optimization, the server fetches the workspace have
list only once at the start of the sync command. When it syncs to change
5 it (correctly) removes the file from change 8, but when it gets to the
second argument, it refers to the now out-of-date have list and decides
that file is up to date so it doesn't fetch it again.

The workaround is to run two sync commands, although this syntax also
seems to work correctly: p4 sync //depot/... at 5,@=8


More information about the perforce-user mailing list