After too much time of searching what could be the cause of a really strange but simple-looking problem and not finding anything on the internets, I came here to dip in the knowledge of the people of StackOverflow. Here is my situation:
In P4V, I right-click on a file > Get Revision... > Get latest revision selected, with Force Operation (replace file even if you already have the revision specified) checked.
But then, in the console panel: file(s) up-to-date. no files updated
What is going on? What is the Force Operation option for, if it doesn't force the operation?
The red check mark indicates that the file is open for edit (or “checked out” in P4V’s parlance), which protects it from being updated by a sync operation (that’s “get” to P4V). The “force” sync option will overwrite a file that’s manually been made writable, or a file whose contents have accidentally gotten out of sync with the depot through some other misadventure, but it will not overwrite a file that has been explicitly opened for edit, since an opened file is assumed to have local changes that have not been submitted.
Right-click the file and “Revert”. That will explicitly discard your local changes and return the local file to its state as of the last time you synced it from the depot.
Related
I made changes to a file directly from the file structure without checking it out from perforce, and while the textual changes show up if I open the file from the Perforce client, the file is not marked as modified (in the P4V workspace). Is this normal?
One of the reasons P4 is so speedy is that it's not constantly checking to see if you made changes without its knowledge.
Right-click on the directory from within P4V and choose "Reconcile Offline Work..." and it will check to see the current status and provide you with any relevant options (in this case, pointing out the file to check out as well as displaying that it has been modified).
My problem is not the "scary" issue of perforce overwriting my files, but the opposite, that it doesn't.
I want to be synchronized with code other people wrote, so I am doing in perforce: "get revision" and then "force operation" from the stream everyone are submitting their work to (after saving a backup of course for the file I am working on in my computer), but when I open the file in eclipse it remains with my changes.
Further - I am doing some small, deliberate changes in my file, and "get revision" and then "force operation" to it, and the same happens.
I have been working in the same workspace for the last days, and when I did it yesterday it overwrote my files, as expected.
Also, in the "submitted" tab in Perforce this file is not in the list, so I didn't accidentally submitted it somehow.
Also, by opening the file from the File System, my changes remain, so it doesn't seem like a problem with eclipse refreshing or something like that.
Ay idea, anyone?
If the file is recorded as "open" in Perforce (i.e. it is returned by the "p4 opened" command, or it appears in the "pending changes" tab in the GUI), even a force-sync won't overwrite it, because you're still working on it. If you want to discard your changes to get something someone else submitted, do one of these two things:
Sync as normal, then resolve with "accept theirs".
Sync as normal, then revert. (Or revert, then sync.)
The first option leaves the file open; the second option does not.
If you want to save a backup of your current work in Perforce (without submitting it), rather than making a local copy of it, you can "shelve" the pending changelist, and "unshelve" it at a later date to return your workspace to the shelved state.
I have a few files that have been edited by an external IDE, I forgot to Check Out the files before making the changes however when I look at the files through P4V the files have changed but the indicator for the file itself shows as nothing has changed. How can I ensure my changes are committed without loosing what I have done?
One way I was thinking was to making a copy of the file, revert, check out, copy content or replace file.
That is OK with a few files but what happens when you have done so with hundreds of files?
The "check out" command doesn't modify the local file, so you can just do that on its own without having to make a backup copy of the file first. (What you want to avoid doing is "get latest", although if the local files are writable, Perforce will automatically balk at updating them by default because of this exact situation.)
If you have lots of files that might or might not have been modified in different ways, use Actions > Reconcile Offline Work, or "p4 reconcile" from the command line. This will find the locally modified files and open them for the appropriate action.
The P4V way to do this is called "Reconcile Offline Work": http://www.perforce.com/perforce/doc.current/manuals/p4v/Offline.html
Or, at the command line, you can use 'p4 reconcile': http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_reconcile.html
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.
HTH.
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).
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
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.
Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.