Update a client workspace’s have list without actually copying any files.
p4 [g-opts] flush [-f -L -n -q] [[FileSpec][revSpec] ...]
p4 flush can cause commands to behave in unexpected ways, so use it only when the situation is appropriate. See the two Examples.
The p4 flush
command performs only Step 2 of p4 sync
FileSpec
two-step operation:
Step 1: The file revisions in the FileSpec
are copied
from the depot to the client workspace.
Step 2: The workspace’s have list (which tracks which file revisions have been synced, and is managed by the Perforce service) is updated to reflect the new client workspace contents.
Under most circumstances, this is not desirable, because a client
workspace’s have list should always reflect the workspace’s true
contents. However, if the workspace’s contents are already out of sync
with the have list, p4 flush
can sometimes be used to
bring the have list in sync with the actual contents. Because p4
flush
performs no actual file transfers, this command is
much faster then the corresponding p4
sync
.
|
Force the flush. Helix Server performs the flush even if the client workspace already has the file at the specified revision. |
|
For scripting purposes, perform the flush on a list of valid file arguments in full depot syntax with a valid revision number. |
|
Display what the results of the flush would be without actually performing the flush. This lets you make sure that the flush does what you think it will do before you do it. |
|
Quiet operation: suppress normal output messages. Messages regarding errors or exceptional conditions are not suppressed. |
|
See Global Options. |
Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
---|---|---|
Yes |
Yes |
|
Because p4 flush
updates the have list without
copying files, and p4 sync
-f updates the client workspace to match the have list,
p4 flush files
followed by p4 sync
-f
files
is almost equivalent to p4 sync
files
. This means that a bad flush can be
almost entirely fixed by following it with a p4 sync
-f of the same
file revisions that were originally flushed.
Unfortunately, this is not a complete remedy, because any file
revisions that were deleted from the have list by p4
flush
will remain in the client workspace even after
the p4 sync
-f. In
this case, you will need to manually remove deleted file revisions
from the client workspace.
p4 sync
-k
.Ten users at the same site need to set up new, identical client
workspaces from the same depot at a remote location over a slow link.
Typically, each user would run identical p4 sync
commands, but if
bandwidth is limited, there’s a faster way:
p4 sync
files
from the client workspace
firstworkspace
.The other users run p4 flush files
@firstworkspace
, which brings their client
workspaces' have lists into sync with the files copied into the
client workspaces in the last step.
Because p4 flush
moves no files across the
slow link, the process can be much faster then running the same
p4 sync
command
ten separate times.
Joe has a client workspace called joe
that has a
Root:
of/usr/joe/project1/subproj
and a View:
of//depot/joe/proj1/subproj/...
//joe/...
Joe decides that all the files under /usr/joe/project1
need to be included in the workspace, and uses
p4 client
to change
the Root:
to /usr/joe/project1
and the View:
to //depot/joe/proj1/... //joe/...
.
This keeps his current client workspace files in the same place
while extending the scope of the workspace to include other files.
But when Joe runs his next p4
sync
, he is surprised to see that
Helix Server
deletes every non-open file in the client workspace and replaces it
with an identical copy of the same file!
Helix Server behaves this way because:
Therefore:
The efficient solution in this case is to use p4 flush #have
to update the client workspace’s have list to
reflect the "new" locations of the files without actually copying any
files.
|
|
To copy files from the depot to the client workspace |
|
To bring the client workspace in sync with the have list after a
bad |
|