Perforce Command Reference:   [Index] [Prev] [Next]


p4 flush

Synopsis

Update a client workspace's have list without actually copying any files

Syntax

p4 [g-opts] flush [-n] [file[revRange]...]

WARNING

Using p4 flush incorrectly can be dangerous. If you use p4 flush incorrectly, the server'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.

Description

p4 flush performs half the work of a p4 sync. Running p4 sync filespec has two effects:

p4 flush performs only the second of these steps. Under most circumstances, this is not desirable, since a client workspace's have list should always reflect the client workspace's true contents. However, if the client 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. Since 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

-n Display the results of the flush without actually performing the flush. This lets you make sure that the flush does what you think it does before you do it.
g_opts See global options section.

Usage Notes

Can File Arg Use
Revision Specifier?
Can File Arg
Use Revision Range?
Minimal
Access Level Required
Yes Yes read

Since 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, since 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.

Examples

Since p4 flush moves no files across the slow link, this process can be faster then running p4 sync ten separate times.
/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 using 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's surprised to see that Perforce deletes every closed file in the client workspace and replace 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.
If Joe had understood how Perforce works, he 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.

Related Commands

To copy files from the depot to the client workspace p4 sync
To bring the client workspace in sync with the have list after a bad p4 flush p4 sync -f



Perforce Command Reference:   [Index] [Prev] [Next]


Copyright 1999 Perforce Software.
Contact us at [email protected]
Last updated: 09/15/99 (Manual version 99.1.cr.6)