Trusty computer crashed and died while files were checked out under a Perforce Workspace. The New computer was not recognized by the old Workspace so I couldn't check the files back in. Had to keep working so I created a new Workspace to edit the exact same files.
I couldn't remove the old Workspace without reverting the files. But I don't want to risk copying over the work I've done on the exact same files under the new Workspace.
Is "p4 revert -k" what I want to do?
Suggestions? Thanks.
What you're really asking is how you can revert files in an old workspace/client that you can no longer access (because it's tied to a host that no longer exists).
The simplest way would be to ask your Perforce administrator to delete your old workspace. Someone with administrative access to your Perforce server can do p4 revert -C OLD_CLIENT to revert files belonging to another user and client, or the administrator can do p4 client -df OLD_CLIENT to delete the client outright.
If you want to do it yourself instead (note: I don't have a Perforce installation handy right now, so this is untested), then you could try:
Run p4 client OLD_CLIENT, clear the Host: field. Save and exit. This should allow further edits from a different host.
Run p4 client OLD_CLIENT again. Change Root: to point to some empty directory. Save and exit.
cd to the directory from step 2. Run p4 -c OLD_CLIENT revert ....
Related
I've set up a new workspace in /Users/sylwester/test and checked for get all revisions and switch to workspace. Every time i start p4v and select my workspace after login I get this error. The command it says it has performed is:
p4 changes -s submitted -l -m 100 /Applications/...
The p4v executable is of course in the /Applications/ directory but my workspace in /Users/sylwester/test. To be sure it was not fixed at a later version i upgraded p4v to 2017.2 (P4V/MACOSX1011X86_64/2017.2/1518788)
It sounds like you have a filter somewhere (probably the history or submitted changelists tab?) that specifies /Applications/... as the path. If you clear or fix that I'd expect the error to go away.
I am trying to look up history for a workspace in p4v. I believe I changed the root directory at one point, and the updated root is shown in the workspace info from p4v and from command line. However, I get the following when I attempt to review history.
Path 'c:\path_to_old_root\...' is not under client's root 'c:\path_to_new_root'.
The Perforce command run is:
p4 changes -s submitted -l -m 100 c:\path_to_old_root...
Additionally, when looking at the workspace in the selectro on the left side pane it shows c:\path_to_old_root\ for the local directory.
I am unsure why it is the generating the command/determining local directory to use in the manner it is.
Not sure why this occurred, but it appears files in the .p4qt directory were not correctly updated. Based on the suggestion that deleting said directory might be helpful, I searched the directory for occurrences of the old root path and replaced them with the new root path. This appears to have corrected the problem.
I've got a following problem:
There are many huge files(gigabytes) on repository, they are not yet in my workspace, but I already have them on my local disk from other source(the same copy as the latest revision).
Is there any possibility to move these local files to appropriate subdirectory of my workspace and mark them on P4 server, that they are the same as latest revision, so I don't have to download them again?
Thanks in advance
The p4 flush command should do the trick here. In this situation, you would copy the files to the appropriate location in your workspace, then run:
p4 flush //path/to/file.ext#head
You can do an entire folder using:
p4 flush //path/to/folder/...#changelist
I am looking for a perforce integrate/get-latest command which would fetch the latest/updated-code and remove the files/folders that have been moved/deleted from the perforce(server) repository.
Is there any way by which I can get a clean copy of the perforce repository, without creating a new workspace/local directory?
Thanks for your interest.
What you're looking for is the sync command. It will grab the latest files, and it will remove any files that were deleted. I'm pretty sure it won't remove the directories, though, at least not on Windows.
To get a clean copy, you can delete the local files, and sync using the '-f' flag.
As of release 2014.1, you can get a clean copy of the repository by using "p4 sync" and "p4 clean". The "p4 sync" command will fetch the latest versions of files from the repository; the "p4 clean" command will remove/refresh anything in your workspace that was not put there by a sync:
http://www.perforce.com/blog/140501/p4-clean-make-workspace-shine
Setting the "rmdir" option in your client spec will tell "sync" and "clean" to remove empty directories as they are emptied by those commands:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#d0e7978
I am new to use svn and the company in which I work uses three levels (I don't know whether this is a correct word to use here) of svn. I mean the developers are provided a working directory on a testing server. When we commit, it goes to the dev server. When a manager commits it from there it goes to production server. I am a developer here and one of my files is giving error (conflict) when I commit from directory. Not only, but also it gives conflict when manager tries to commit. I am now given access as manager too but I am still unable to resolve it.
What I've tried till now:
svn update
svn delete
svn commit
It gives conflict on all of these operations.
Earlier on a simple error happened and the manager preferred to just delete file on dev, copy it manually and then commit from there. I don't know this may be a reason of this problem or not.
Please help me resolve this issue. I've read some things in read-bean book too but to no avail yet.
Thanks
Ok, here's the update. The actual problem is that a file (ex lib/a.php) used to be in my working directory as well as in dev and production servers. Now it was deleted by someone (using del command, not svn delete) from dev server. Now question here is how I add it again so that it becomes part of svn again. The simple svn add doesn't work.
Update 2
From one of the answers below I understood that its a tree conflict. Some searching brought me to http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html . Following the instructions, I took the backup of the file and then svn delete it from everywhere. Then I svn add it to my directory, commit it and tried to update dev and production. End result is that it doesn't go there. No error is shown either.
svn info in my directory shows complete info of the file but on dev and production it shows
file_name: (Not a versioned resource)
:S
Any more ideas please?
Alternatively you can take backup of the file ,then say svn revert filename insert you new code.Do a svn up just to make sure you do not have any conflicts,and then commit
Or
fix the conflicts in the file and then you can say svn resolved filename and then you can continue operations on the file
Update:If your file is deleted using rm or del command use svn revert filename to get it back and you do not have to add it again.Just put in your new changes and say svn ci -m"your comments" filename
svn revert will fetch back the last checked in copy into SVN and it wouldnt have your any changes made before the user had used del command
Update 2:After u say svn delete ,u need to commit it until u get the message Deleting filename with a new revision number.Then add the file using svn add command,then commit again.Once this is done you can check the svn info, let me know..
Use svn status command to know the status of the file
The only problem apart from this i can think of is this the directory may not have been added.Is this a new directory?
ah, the old tree conflict problem.
The issue is that SVN is letting you know that you're adding a file that used to be there but it cannot tell whether you're trying to delete it, add it or just update it! So it does the only thing it can - flags a conflict so you can sort it out and fix it. Its basically a conflict on the directory level (rather than a conflict of a file's contents).
What you do is resolve the error (as others have pointed out), then update the directory to get the original file back, then commit your changes. Note that the file was never deleted from SVN - its still in the repo, and if you checkout out a new WC, you'd get the file.
Try to resolve the conflicts then commit again:
svn resolve --accept working