Perforce Revert Shows "file(s) not opened on this client"

perforce revert file to previous version
perforce undo revert
p4 revert files not opened on this client
perforce undo checkout
rollback change perforce
p4 revert hangs
p4 delete changelist
p4 revert deleted files

I'm trying to open an existing Perforce application. I made some local changes, like deleting files, which I want to undo (that is, I want my local copy to exactly match the repository once more -- delete added files, restore deleted files, and undo changes).

When I try to revert using the p4v gui client, I see this error:

 file(s) not opened on this client

What am I doing wrong?

I did manage to revert all the changed files, but not the added/removed files.

Edit: I did the following:

  • Connect to a Perforce server using p4v
  • Map a directory to my local file system (lets say C:\Perforce)
  • Get the latest version of the repository
  • Go to C:\Perforce in Windows Explorer
  • Delete some files and folders
  • Add some files and folders

I would like to get back to the "pristine" state, the copy of exactly what's on the server when I got the latest version of the repository for the first time.

By the looks of the edited description you added and deleted files directly on the filesystem and not through perforce. Therefore Perforce doesn't know anything about those changes so there is nothing to revert. Typically when you want to add a file you use 'p4 add" (or the equivalent p4v operation), and when you delete, you should use 'p4 delete' (or again, the equivalent p4v operation).

Really, the best option to get back to a pristine state is to nuke the local copy of the code in c:\perforce (in windows explorer), go to p4v, right click the area you want to sync, and choose "Get Revision..." and in the subsequent dialog, make sure that the "force operation" checkbox is checked. This will tell Perforce that you want a new copy of everything regardless of whether you had it synced or not.

You can also run "reconcile offline work" in p4v. Right click the depot area and choose that option. It will scan through the local folder structure and give you a report of what files have been added that don't exist in perforce, what files were deleted, and what files were modified. From that dialog, you can right click on local files that don't exist in perforce and delete them, or you can 'p4 add' them. You can also sync deleted files.


p4 revert, 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  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.

Just an extra not to point out another cause for this. If the file name contains an unusual character that cannot be translated correctly the name on the client will never match that on the server. The solution in this case is to spot that character in the file name (it will be a question mark emblem on Linux) and use a wildcard to help identify the file to the server so it can delete it etc (p4 deleting the file is a way to go).

p4 revert // P4 Command Reference, VCS | Update Project or VCS | Perforce | Update File/Directory. Context menu of a file or directory This option corresponds to the Perforce revert command. See p4 revert reference for Do not show this dialog in the future. If this checkbox is  Therefore Perforce doesn't know anything about those changes so there is nothing to revert. Typically when you want to add a file you use 'p4 add" (or the equivalent p4v operation), and when you delete, you should use 'p4 delete' (or again, the equivalent p4v operation).

This answer may not be your case. This happened to me when I edited the files on my local disk without logging into p4.

A quick fix at commandline is:

p4 login               # make sure you've logged in
p4 edit <filename>     # let p4 know you've edited the file
p4 revert <filename>   # revert to "pristine" state

Update Project dialog (Perforce) - Help, txt tampered with before resolve - edit or revert. It seems no matter what I do, I am unable to make this issue go away: the next forward integration will show a  Reverting Another User's Files. How to revert files for a Perforce Helix Core user or client that no longer exists. How to revert files opened in another user's client workspace

Perforce: File tampered with after resolve - edit or revert, SO goes back to an unchecked out state, but the modified value still shows. Clearly Unity recognized Perforce's revert, but didn't revert the  p4 revert differs from most Helix server 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.

When Perforce Revert Outside of Unity the Custom Inspector Isn't , Discussion: Perforce: Revert if unchanged broken Perforce Visual Client/​NTX86/2005.1/83219. previous version and be sure to set the diff tool to show all Reverting unchanged Perforce Helix Core files, files which you did not change are not reverted. Running a diff does not show any difference in contents between local files and the same files on the server. When reverting unchanged files,

Perforce: Revert if unchanged broken, Be careful of p4 revert -- Perforce's revert command overwrites any changes that If this is selected, a 'Submit' without adding a description shows the Perforce  This command will open in your workspace the files modified in Changelist 12345. Those files will have the content as of their previous revisions. Once you submit the opened files, the effects of Changelist 12345 are undone. p4 undo also supports revision ranges to undo multiple changelists at once.

  • What do you mean by "open an existing perforce application"? Are you talking about a client (like p4v) or something else? When you deleted and added files, did you do so with either the 'p4 add' p4 'p4 delete" commands? or by their equivalents in the p4v gui? Also, when you say you want your local copy to match exactly do you mean file by file identical to what's in the depot (no extraneous files at all), or do you mean that you want the files in your workspace to match the depot and having extra files in your workspace are okay.
  • @Mark I've updated my question with details.
  • Did you add and delete the files through Perforce?
  • @MikeO'Connor no, and I don't want to. I just want to revert my workspace and discard all my local changes.
  • This is what I wanted to know. SVN, Hg, etc. all allow you to use revert to delete local files not in the repository and re-add deleted files that are still in the repository.
  • Perforce will only keep track of files that it "knows" about. So when you delete local files that are not stored in the repository, Perforce doesn't know anything about them. Just keep in mind that anytime you act on files in your workspace, if you want perforce to know about it, you have to use Perforce commands (or then use something like reconcile offline work to get back in sync with what Perforce thinks that you have locally on your workstation)
  • that's understandable. What I don't understand (maybe because of my SVN/Hg background) is that Perforce seems to "ignore" the file-system and not allow you a one-click revert to exactly what's on the server. That seems like a usability failure to me.
  • You can call it a usability failure, but many will see that as a plus - it's simply a different paradigm. Perforce is super fast for nearly all of its operations because it keeps track of what is on your local workspace and doesn't have to do any kind of fixups to make your workspace match what's on the server unless you tell it to. This change in thinking (and this speed) really shines when you have workspaces of 500K+ files. Working on data sets that large is still blazingly fast in Perforce.
  • +1 @Mark for the explanation of how the paradigm differs