My hard disk crashed and i lost all the files in the shadow (client workspace). Now after reinstalling perforce I can see my workspace from the GUI (all the root-view mappings).
Any pointers on how to get all my client workspace files back.
Please help.
You can't. If that disc is no longer functional, then the files that were on it are lost. Workspace definitions are stored on the server, but the files they contain are not.
Related
I have a some project in my apps folder and those were deleted permanently. how can i recover it from command line,apps folder contains some folders like project_1, project_2 etc. and project_1 folder contains files.
Depends on how long ago it was. If this was just now, shut down the system immediately and take a disk image. Foremost is the usual tool for file recovery, but as your partition is intact you might try some things like extundelete. If you deleted it a few days ago, it's probably mostly gone.
I hope I'm not asking a question that's already been answered, but I can't seem to find one that fits my situation.
Scenario: Using P4V gui (2011 version), with no access to P4 command line, on Windows 7.
The setup: A user creates a workspace in Perforce from Machine A, pointing that workspace to a shared network drive, and checks out a file for editing.
Machine A then dies before the user can check in the file. The user is then assigned Machine B, for which he must create a new workspace (which is also pointed at the same shared network drive).
The problem: The problem we're having is that even though the workspace from the dead Machine A and from the new Machine B both point to the same location, Perforce considers them to be different workspaces and prevents the user from checking in/submitting the previously checked out file.
Any suggestions on how to check in this stranded file would be greatly appreciated. Thank you very much!
To be nice and clean, I'd suggest this:
Make a backup copy of the file as it exists on the shared network drive.
Connect to the depot from Workspace A (can be done from Machine B if the workspace isn't bound to Machine A).
Revert the file - this will overwrite the file on the drive with the version in the depot (aren't you glad you made a copy first?).
Switch to Workspace B.
Check out the file.
Copy the backup version over the file on the shared network drive.
Check in the file.
...and if you're not planning on using Workspace A anymore, I'd suggest deleting it.
Have you tried clearing out the Host field? For example, see 'Using the same workspace from different machines':
http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.configuration.html#d0e1720
As an update from my comment response, if you need to change ownership of a changelist, the steps are documented here:
http://answers.perforce.com/articles/KB_Article/Changing-the-Owner-of-a-Pending-Changelist
Recently our development team received new pc's. In an effort to make this transition smoother, I would like to be able to explain to my co-workers how to continue using the client they already have set up to pull files to and from the new pc while eventually ignoring the old pc workspace altogether.
I know about adjusting the attributes of the client itself and allowing the client to be accessed by different hosts. What I'm looking to do now is update the perforce have list for the given client to reflect the files (or lack thereof) that are on the new pc's file system (in the correctly mapped location, obviously).
I'm not sure if it is possible with the p4 flush command for perforce to know which revision of an existing workspace file i have without explicitly telling perforce which revision it is...? (this seems like its asking a lot)
Apart from files that Do exist in the workspace, is there a command that will update the have list to #0 for files that don't exist in the workspace?
OR
Is the sledgehammer approach:
submit any pending changes in the old and/or new workspace
remove any files that may have already been forced into the (new) workspace
$:p4 flush [workspace root]/...#0
appropriate in this situation?
If using the existing workspaces is an option, then this should be pretty easy. It sounds like you already know how to make a workspace accessible from a different host (you can leave it blank to make it accessible by any host). If you copy the workspace folder to the new PC, and update the root of the workspace as necessary, it should "just work" without any additional changes.
If I'm understanding your question correctly, I believe that using a workspace name as your revision modifier will do what you want. For example p4 flush //depot/path/some/file#workspacename. For new machines, we often go through these basic steps to avoid having to resync files.
Copy the files in the workspace from machine 1 to machine 2
Create a client that matches the old client's mappings
In the new client, run:
p4 flush //depot/...#oldclientname
I deleted files accidentally in Dreamweaver.
How to recover the file ?
I use Dreamweaver since many years. I don't know this function. Here are the possibilities I see:
You should recover the file fom your repositoty if you use that.
Or maybe you could also try to recover thatfile with the windows recovery functions.
You could try to run a file recovery program.
Recover that file from its orginal source if that is not your work.
Recover that file from the webspace ehere the file is online.
If it's a local file, it ends up in your Recycle Bin (on Windows at least).
Files deleted through FTP are lost and may be only recovered by storage recovery software.
(I know the question is 2 years old)
I forgot to check out a source code file before modifying it.
When I get last revision, Perforce overwrote that file, so my work is totally lost.
Is it possible to recover the file?
For future use, update your client workspace so that you specify "noallwrite, noclobber". If noclobber is set, Perforce will not overwrite your writable un-opened files: http://www.perforce.com/perforce/doc.current/manuals/cmdref/client.html
Only if your editor or your operating system saved a copy or it's been modified long enough that it made its way to your backups. Perforce will not make copies of such files, it blindly assumes that you didn't lie and will always honestly tell it when you want to edit a file.
if you are using eclipse then its possible to retrieve the local version using Compare With -> Local history . It helped me.
This has happened to me recently. For some reason, after I "p4 sync"-ed my workspace, and do p4 resolve, I noticed that my changes to a file were missing. I'm not sure if my changes were not saved or I haven't checked out the file. But I really remembered that my changes were saved. :(
I have been using Visual Studio for development and it doesn't have local history unlike in Eclipse. Luckily, that file is a javascript file and I have been testing my application in Internet Explorer. Since IE does some caching on some internet data like js files, what I did is to check the directory where it saves temporarily files (Internet Options -> Browser history settings ) there you'll see different versions of the files saved. I did recover my files! It was really just luck!
After that incident, I installed a plugin for visual studio for storing local history of files everytime it's being saved. http://visualstudiogallery.msdn.microsoft.com/226c2108-9da9-407d-b90d-9783040d27b8
Best thing to avoid these cases is to:
branch out your files first into a separate devline during development and submit every milestones you accomplished
incrementally. In this way you'll always have versions of important
changes you do during development. After this you could
integrate it back to the parent branch/mainline.
http://answers.perforce.com/articles/KB_Article/Branching-Codelines-and-Merging-Changes
Hope this helps!
If you fired the following command (which is a FORCE sync option), only then will Perforce update ALL your files.. including ones which are WRITABLE. The only exception is that any file that you have OPENED in perforce will not be overwritten. So if your file was made WRITABLE using OS command, and not using p4 open.. they will get overwritten by p4 sync -f.
p4 sync -f
The other possibility is that you did p4 sync, and still perforce overwrote your writable files (which were not opened using p4) because your workspace settings don't have noallwrite, noclobber specified. Usually by default, these settings are already specified, so that Perforce doesn't clobber writable files.