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

Question

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.

Romilda

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. – Ghostwrite

@Ghostwrite I've updated my question with details. – Romilda

Did you add and delete the files through Perforce? – Tallu

@MikeO'Connor no, and I don't want to. I just want to revert my workspace and discard all my local changes. – Romilda

Answer 1

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.

HTH.

Ghostwrite

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. – Romilda

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) – Ghostwrite

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. – Romilda

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. – Ghostwrite

+1 @Mark for the explanation of how the paradigm differs – Marshall

Answer 2

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).

Noblesse

Answer 3

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

Fancywork

Answer 4

You can use p4 reconcile -w to restore your client to the state of the server. There is an alias called clean, which is also available in P4V on the right-click context menu as Clean....

There are several additional flags to control whether added and deleted files are deleted or restored, respectively.

The -w flag forces the workspace files to be updated to match the depot rather than opening them so that the depot can be updated to match the workspace. The -a, -d, and -e flags when used with -w update workspace files as follows:

-a Files with no corresponding depot file are deleted. -d Depot files not in the workspace are added. -e Modified files are restored to the last version synced.

Savell