I made my change successfully did a p4 change and have a numbered CL.
p4 describe -c 27701190 indicates it is pending, however p4 pending and p4 opened indicate "File(s) not opened on this client".
It's not critically important that my client be updated, but I'd like to submit this CL. (I'd also be happy with getting my client situation rectified).
What's the path to either submitting this CL or opening the files involved in this CL on my client?
You can open the files for edit after the fact (i.e., after you've changed them without telling Perforce you were going to change them). Just run the edit command and open them in the desired changelist with the -c switch:
p4 edit -c 27701190 "//depot/path to files/..."
Related
I have a large perforce client already synced. I realized that I'll only be working on a sub directory of the larger root folder I synced to.
Old p4 client specs
//Depot/largeFolder/... //Clinet/largeFolder/...
New p4 client
//Depot/largeFolder/samllSubDir/... //Clinet/largeFolder/smallSubDir/...
Now when I perform a p4 sync perforce doesn't remove the other folders which I don't want in my client.
I'm hesitant to do a p4 sync -f since I have files edited in the /largeFolder/smallSubDir/. I don't want them to get reset.
What is the right way to sync my client so that the other folders which are not in the new mapping are removed?
Note: My real mapping is complicated and deleting folders by hand is not realistic.
In the typical case, re-syncing a narrowed client will indeed remove the unmapped files. You don't say what happens when you try to do a sync (are there error messages?), so I can't say for certain what's going on, but these are the two first possibilities that come to mind:
Opened files will not be touched by a sync, ever. You need to revert them -- use the -k flag if you want to revert the files but keep your local copies, and then use the -k flag on sync as well so that it will continue to not touch them (while marking them as having been synced, or in this case un-synced).
Writable files will by default be left alone by a sync, and produce "can't clobber" warnings. Doing sync -k should suffice here if you want to keep the local files. Doing sync -f will blow away the local files even if they were modified (but only if they're not also open for edit -- see above).
Useful commands to run if you're trying to debug (pick any file that's not getting [un]synced that you think should be):
p4 sync <file> -- do you get an error message that tells you why the file isn't being removed?
p4 where <file> -- is the client mapping for that file not what you think it is?
p4 opened <file> -- is the file opened?
p4 have <file> -- did you even sync this file in the first place?
p4 files <file> -- does this file even exist in the depot?
Note that the fact that opened files will not be touched by a p4 sync means that your edited files will be safe from a sync -f, provided that you actually opened them for edit. If you didn't, run a p4 reconcile and then p4 sync -f is perfectly safe -- but if you don't get to the root cause first (i.e. are the unwanted files also opened for edit?), it might not be helpful either.
My p4 client version is P4/NTX64/2018.1/1705517.
I noticed that some files had accidentally been deleted in my workspace. I synced, but even so, the files did not appear.
I then ran the p4 have command and saw that it contained the missing files, and so p4 will not include those files in the sync.
Of course I can give the p4 sync command with the -f flag, but my workspace is rather large, so that would take a long time.
I then ran the flush command even with the -f flag thinking that it would correct my have list to reflect what I actually had on the filesystem of my workspace, but it didn't. What am I doing wrong?
p4 flush changes the have list to match whatever you tell it to match (if no arguments, then #head is the default). If that's not what your workspace actually contains, then the have list is now out of sync with the workspace, and future p4 sync commands will probably skip a bunch of files (exactly like you're seeing now).
The command you want is p4 clean, which syncs your workspace to match your have list. (If you have changes in unopened files, including "new" files that you haven't opened with p4 add, this will irrevocably blast them. Careful!)
If you want to open the files that don't match your have list, use p4 reconcile instead. (You can follow it up with p4 revert to discard the changes, or p4 submit to keep them permanently.)
A person changes his laptop and discarding this perforce client and workspace. He had 2 files opened in a changelist but not sure on the changelist number.
I have admin rights and tried to unlock the file but couldn't do it
p4 -p p4ser:1001 unlock -f //doc/pascal/projmng/GP.xlsm
//doc/pascal/projmng/GP.xlsm - file(s) not opened in that changelist
Then i tried to find the change list by searching for opened files by that user
p4 -p p4ser:1001 opened -u joe | grep GP.xlsm
//doc/pascal/projmng/GP.xlsm#5 - edit default change (binary+l) by joe#joe_dt exclusive
I have the client name now as joe_dt and was able to find the changelist using changes
p4 -p p4ser:1001 changes //doc/pascal/projmng/GP.xlsm
Change 34784592 on 2015/05/28 by joe#joe_dt 'added POR stuf'
Now if i try to unlock, i get the same error.
p4 -p p4ser:1001 unlock -c 34521298 -f //doc/pascal/projmng/GP.xlsm
//doc/pascal/projmng/GP.xlsm - file(s) not opened in that changelist.
So now i have the client name alone which does not exists as the laptop was replaced. Don't know in which changelist this file is opened by the user joe.
Unlock -x also didn't help.
Am new to Perforce, can you guys help me how to unlock this file?
First, do this; it'll save you from having to keep typing "-p p4ser:1001". :)
p4 set P4PORT=p4ser:1001
The file's not "locked", it's "opened exclusively" -- these are two distinct states, and "unlock" only deals with the "locked" state.
A file can be "opened" but not "locked", and "unlock" takes a file from "opened+locked" to just "opened". Multiple people may have a file "opened" at the same time, even if one has it "locked", but nobody else can "submit" while somebody else has a lock.
A file with the "+l" filetype, though, is always opened exclusively, regardless of whether it's "locked" -- only one person can even have it open at a time. To release this the user who has the file open needs to either "submit" or "revert" it -- they can't release the lock while also keeping the file open as you can with a normal "lock". For an admin to release the file without deleting the client, they need to actually force a "revert" rather than a simple "unlock".
But since joe has discarded this client workspace, the simplest thing is to just delete it:
p4 client -d -f joe_dt
That should cause any files previously opened on that client to be abandoned, whether they were locked, exclusive, both, or neither.
I have a workspace in perforce in which I made some files mark for delete. Now I want to delete that workspace forcefully.
But I don't have admin rights. How can I achieve this?
Run p4 opened to see all your opened files and run p4 revert to revert them.
Then run p4 changes -c your-client-name -s pending to see all your pending changelists. Since in the first step you reverted all your open files, these changelists will all be empty. Run p4 change -d change-number to delete each empty pending changelist.
Then you can run p4 client -d to delete your client.
Why it's only 11 clicks in P4V, through an arbitrary sequence of menu items.
Right click on the changelist
Delete shelved files
'Yes'
Right click on the changelist
Remove all jobs
Right click on the changelist
Revert files
'Revert'
Right click on the changelist
Delete pending changelist
'Yes'
Let's send Perforce to usability school.
Here's a scriptable procedure for deleting a Perforce client. Use with care: this deletes all your work in progress on the client!
Revert all changed files on this client.
p4 -c $CLIENT revert -k //...
Note the use of the -k option, which "marks the file as reverted in server metadata without altering files in the client workspace". Since we are going to delete the client later, we don't care about updating the client workspace. This speeds things up if you have many files open.
Delete all shelved files from pending changes associated with the client.
p4 changes -s shelved -c $CLIENT | cut -d' ' -f2 |
while read CHANGE; do p4 shelve -c $CHANGE -d //...; done
If you never use p4 shelve you can omit this step.
All pending changes associated with the client are now empty. Delete them.
p4 changes -s pending -c $CLIENT | cut -d' ' -f2 | p4 -b 1 -x - change -d
There are now no pending changes associated with the client. Delete the client.
p4 client -d $CLIENT
(This process ought to be much easier! In particular, there seems no good reason why we have to delete shelved files associated with a client before deleting the client. If you find yourself struggling with this, do contact Perforce support and suggest that it be made simpler.)
Here is what I did to empty my default change set, which had a lot of files checked out for edit:
p4 opened | sed 's/#.*$//g' | xargs -iF p4 revert F
This will cut off the comment part from the filename produced by p4 opened and pipe the filename to p4 revert. After that I had nothing pending and p4 changes -c my-client-name -s pending yields nothing. If you have a huge change set this will take a while.
Wrote this script called p4-delete-client for deleting a p4 client (which has changelists & other problems).
It has the following features:
automatically deletes changelists (reverts pending & deletes shelved)
fixes hostname (if differs from the one the client was created on)
unlocks the client if locked
deletes the client
deletes associated files (can be configured not to from arguments)
Note that the script relies on other scripts in the repo.
try those steps :
1.Right click on the changelist
Choose 'Change Ownership'
In the workspace box choose already existing workspace and click OK
right click on changelist and choose delete and than ok.
All the files need to be reverted before the change list can be deleted.
Two steps via p4v (version 2013.4):
Revert all files.
Right click the pending changelist, and then choose "Revert Files"
Delete the change list.
Right click the changelist, and then choose "Delete Pending Changelist 'XXXXXX'"
This just worked for me in P4V for resetting the default changelist:
Right click on the default changelist and choose "Edit Pending
Changelist 'default'"
Click the button on the bottom right "Save as numbered changelist"
Right click on the new changelist and choose "Delete changelist XXX"
You can also right click on the new changelist to revert the files for whatever you need to do, which is not available as an option on the default changelist.
I had made changes to a file and then shelved it.
Then I deleted the file.
Now I am not able to get it back to my workspace. I tried p4 sync -f and p4 unshelve ##.
What do I do ?
p4 unshelve is the correct command.
To figure out which shelf you need to unshelve, use p4 changes -s shelved and p4 describe -S
What's probably going wrong is that when you deleted the file, you still left it "opened" in Perforce (do p4 opened to see), so first do a p4 revert to revert the file, then you can successfully unshelve the shelf and you'll get your edited version back.
In p4v, go to the depot view, select the file, then hit ctrl-shift-s (pretty sure this works in linux too) this will open an explorer window which should be where the file is located. Maybe it's going to a different directory then the one you think?
If it's not there, right click the folder, and say get this revision, and check the force checkbox