Discard changes made to open files.
p4 [g-opts] revert [-a -n -k -w] [-c change] [-C client] [--remote=remote] file ...
Use p4 revert
to discard changes made to open files,
reverting them to the revisions last synced from the depot (with p4 sync
). This command also
removes the reverted files from the pending changelists with which
they’re associated. An administrator can use the -C
option
to revert another user’s open files.
p4 delete
, the files are
reinstated in the client workspace.p4 add
,
Perforce
leaves the client workspace files intact.p4 integrate
,
Perforce
removes the files from the client workspace.p4 move
, only the file
open for move/add
can be reverted.The host name is implied and the username is not needed.
|
Revert only those files that haven’t changed (in terms of content or filetype) since they were opened. The only files reverted are those whose client revisions are the following:
|
|
Reverts only those files in the specified changelist. Revert all files in a specific change in a client workspace
$ p4 revert -c 345627 "//..."
|
|
Revert another user’s open files. This option implies the
Revert a single file in a client workspace:
$ p4 revert -C bruno_ws //depot/www/dev/Jam.html
Revert all files in a client workspace:
$ p4 revert -C bruno_ws //...
This option is useful in freeing up exclusive locks held on an edge server. In such a case, the command needs to be directed to the edge server where the client resides. For example:
$ p4 revert -C SusanClient //depot/src/x.cc
The option is also very useful in cleaning up after old users' workspaces: you need to revert any open files in a workspace before you delete it. |
|
Keep workspace files; the file(s) are removed from any changelists and Perforce records that the files as being no longer open, but the file(s) are unchanged in the client workspace. |
|
List the files that would be reverted without actually performing the revert. This lets you make sure the revert does what you think it does before actually reverting the files. |
|
Reverts the file in your personal server, and additionally — if
the file is of type For more information, see the section Support for exclusive locking in the Fetching and Pushing chapter of Using Helix Core for Distributed Versioning. For more information, see the section "Support for exclusive locking in personal servers" in the "Fetching and Pushing" chapter of Using Helix Core for Distributed Versioning. |
|
Files that are open for |
|
See Global Options. |
Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
---|---|---|
No |
No |
|
p4 revert
differs from most
Perforce
commands in that it usually requires a file argument. The
files that are reverted are those that lie in the intersection of the
command line file arguments and the client view.
You don’t need to specify a file argument when using the
-a
option.
edit
will
overwrite any changes you have made to the file since the file was
opened. It may be prudent to use p4 revert -n
to
preview the results before running p4 revert
.
To open a file for add |
|
To open a file for deletion |
|
To copy all open files to the depot |
|
To read files from the depot into the client workspace |
|
To list all opened files |
|
To forcibly bring the client workspace in sync with the files that Perforce thinks you have, overwriting any unopened, writable files in the process. |
|