p4 flush
Synopsis
Update a client workspace’s have list without actually copying any files.
Syntax
p4 [g-opts
] flush [-f -L -n -q]
[file
[revRange
]
...]
Description
Warning
Using p4 flush
incorrectly can be dangerous.
If you use p4 flush
incorrectly, the versioning service’s
metadata will not reflect the actual state of your client workspace, and
subsequent Perforce commands will not operate on the files you expect!
Do not use p4 flush
until you fully understand its purpose.
It is rarely necessary to use p4 flush
.
The p4 flush
command performs half the work of a p4
sync
. Running p4 sync
filespec
has two effects:
- The file revisions in the
filespec
are copied from the depot to the client workspace; - 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.
p4 flush
performs only the second of these steps. 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
.
Use p4 flush
only when you need to update the have list to match
the actual state of the client workspace. The Examples
subsection describes two such situations.
Options
|
Force the flush. Perforce 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 the results of the flush 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”. |
Usage Notes
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, andp4 sync
-f updates the client workspace to match the have list,p4 flush files
followed byp4 sync
-f files
is almost equivalent top4 sync
files
. This means that a bad flush can be almost entirely fixed by following it with ap4 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 thep4 sync
-f. In this case, you will need to manually remove deleted file revisions from the client workspace. p4 flush
is an alias forp4 sync -k
.
Examples
-
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. The standard method calls for each user to run identical
p4 sync
commands, but if bandwidth is limited, there’s a faster way:- One user runs
p4 sync
files
from his client workspacefirstworkspace
. - The other users copy the newly synced files from the first user’s client workspace into their own client workspaces using their local OS file-copying commands.
-
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 samep4 sync
command ten separate times.
- One user runs
-
Joe has a client workspace called
joe
that has aRoot:
of/usr/joe/project1/subproj
and a
View:
of//depot/joe/proj1/subproj/... //joe/...
He decides that all the files under
/usr/joe/project1
need to be included in the workspace, and accomplishes this by usingp4 client
to change theRoot:
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’s surprised to see that Perforce deletes every non-open file in the client workspace and replaces it with an identical copy of the same file!Perforce behaves this way because the have list describes each file’s location relative to the client root, and the physical location of each file is only computed when each Perforce command is run. Thus, Perforce thinks that each file has been relocated, and the
p4 sync
deletes the file from its old location and copies it into its new location.To make better use of Perforce, Joe might have performed a
p4 flush #have
instead. This would have updated his client workspace’s have list to reflect the files' "new" locations without actually copying any files.