I have a workspace with shelved files. I am trying to unshelve these files into another workspace by using the command :
p4 unshelve -s sourcechangelist -c destinationchangelist
However I am getting "file not found error"
Could anyone tell what I am missing ?
Thanks in advance !!
If you are getting the literal error message "file not found error" it's not coming from Perforce -- I'm guessing you don't have p4 installed on this machine, or you passed an unquoted wildcard that the shell is failing to expand.
If that error message was a paraphrase, most likely there aren't any files shelved in the changelist you passed with "-s sourcechangelist". Go back to your original workspace and make sure you've shelved the files.
Related
It seems that p4 unshelve -s changelist doesn't bring the new source files that are added in the shelved changelist. Two questions:
Am I missing something?
Any workaround?
Thanks.
p4 unshelve should faithfully open every file that was shelved, for its corresponding action — add, edit, integrate, or delete. The opened file will be opened at the same working revision, with the same resolves (either pending or completed), and the same content.
To answer your two questions:
Yes, you missed something (but there's not enough information to know what).
To work around the problem, figure out what you missed and fix it.
Do the added files show up in p4 files #=SHELF? If not, they were never shelved in the first place. Go back and fix that.
Do you get an error message from p4 unshelve telling you that these files can’t be unshelved? If so, fix that.
Are the files already opened according to p4 opened? If so, either they did get unshelved or that’s the reason they couldn’t be unshelved.
I faced the same issue but for my case it's because of I have file(s) opened for add locally. Target shelved CL that I want to unshelve also has that file(s) opened for added as well. So if I try to unshelve target shelved CL, it will shout out similar to the following error message.
//depot/dir/file.h - can't unshelve (already opened for add)
So I have to do the following
p4 revert <file(s)> - revert all files opened for add. This won't remove the file(s), it will still be there. It will show message like //depot/dir/file.h#none - was add, abandoned
p4 unshelve -s <target-CL> - to unshelve target CL again, this time, there should be no error message. If you already unshelved previously but has error for those file(s) opened for added only, then you can do just p4 unshelve -s <target-CL> <file1> <file2> to unshelve only those file(s) opened for add only.
Done, now you can continue working.
p4 unshleve will open files for add if they existed in the changelist passed to -s.
There exists a case where added files specifically wouldn't be unshelved and that is when the files already exist and are writable. For such files, you should be seeing an error saying:
Can't clobber writable file /file/path
I used to run into this case when I do the following:
Shelve a changelist that has files opened for add on workspace1
Unshelve the changelist on workspace2
Revert all the unshelved files on workspace2, including the files opened for add
Now the files that were opened for add will exist in workspace2 and stay there in a writable state
Unshelve the changelist again on workspace2
If you inspect the output of p4 unshelve here you should see the error mentioned above
Run p4 opened on workspace2 and not find the files that were opened for add
When i try to shelve a change
p4 shelve -r -c 1111111
it fails with errors:
<file x> - unshelved file for <user y> needs resolve
Shelve aborted -- fix problems then use 'p4 shelve -c 1111111'.
There used to be conflicts but they are resolved now, and p4 resolve says there are no files to resolve.
What this is telling you is that another user (user y) has a pending resolve from that shelved revision. Since you're replacing (or possibly removing?) that file from the shelf with the -r option, they might not be able to do their resolve and finish their unshelve operation.
Good lesson here is that if you do a p4 unshelve when you have local changes, make sure to follow it up with a p4 resolve quickly before the owner of the shelf deletes or changes it underneath you! :)
It turned out specifying the force option solved the problem:
p4 shelve -c 1111111 -f
I am trying to setup perforce. I installed p4v and setup workspace.
Then I ran
C:\"Program Files"\Perforce\p4 -p perforce-test:1500 -u test-user -c test-user_test sync //test-folder/test/
But I get error //test-folder/test/ no such files(s)
I can see files and folder exist in p4v depo.
Use the path:
//test-folder/test/...
Directories aren't objects in Perforce, they're just part of the file name -- so you don't sync a directory called "//test-folder/test/", you sync all the files whose paths match the pattern "//test-folder/test/...".
Use the “...” in the end
e.g.
Wrong ： p4 sync //test-folder/test/
Right : p4 sync //test-folder/test/...
I'm currently (and regularly) performing very large integrations (usually 50k+ files). In P4V, it is technically possible to display and manually work with those files, but it's slow and unwieldy.
Is there some way to move unresolved files to a separate CL without needing to write an application? I was taking a look at "p4 resolve -n" but I can't figure out how to use that output with p4 reopen (assuming this is even the best way of doing what I want.)
Any help would be appreciated.
You can use this:
p4 -F %localPath% resolve -n | p4 -x - reopen -c default
Explanation:
-F %localPath%: tells p4 to output paths in local format
resolve -n: means "list unresolved files without actually resolving them". (P4 Resolve)
-x -: Tells p4 we'll be working on a list of files, and '-' means that the list of files is coming from stdin (piped) (p4 Global options)
reopen -c default: reopen incoming specified files in given changelist ("default" can be replaced by an existing changelist number). (p4 reopen)
Update:
For very big changelists, sometimes the command gets stuck. You can do it in 2 steps to workaround the problem:
p4 -F %localPath% resolve –n > c:\p4_output.txt 2>c:\p4_errors.txt
p4 -x - reopen -c default < c:\p4_output.txt
Note: When reopening files that were moved, p4 reopen will only move "half" of the change (the add) and leave the delete in the previous changelist. I haven't found a solution other than moving those manually.
Something like:
p4 -F %localFile% resolve -n | p4 -x - reopen -c CHANGE
ought to do it. (Run "p4 -e resolve -n" to see the list of available variables in the output, I think localFile is the one you want.)
I had a similar problem sometime ago.
To move a Perforce changelist to another computer/workspace,
follow the steps given in the below link:
movng unresolved files/changelists
I am trying to get the last checkin on a particular folder structure on perforce, I know "p4 changes -m1 'filepath" does the job, but the problem is the filepath has to be the depot file-path. What I have on the other hand is the local filepath something like "C:\Android\Version10.2\MyApp\" and not "//depot/Andoid/Version10.2/MyApp".
I tried using commands like "p4 fstat", "p4 where" and "p4 files", but for all of them it works fine with the depot file path, if I give the local file path, it keeps complaining file(s) not on client/no such file(s).
The other issue is I dont have rights to change the p4client on the machine. How do I get this to work?
Basic question then to sum up is being able to get the last change on a folder/file for which I have the local filepath.
Regards
If you're going to run any commands on files those files have to be in the workspace. The problem is probably that p4 on Windows defaults to the machine name as the workspace name if you don't supply one.
So you either have to run set P4CLIENT=<clientname> then run p4 changes -m1 <filename>,
or p4 -c <clientname> changes -m1 <filepath> where <filepath> can be the file on your local file system, so C:\Android\Version10.2\MyApp\ would be acceptable.
Does p4 filelog -m 1 <filename> give you what you want? You can add the -l (lowercase L, not one) switch to get more information.
If you have a local file (as opposed to the depot-path), then you also should have a client-spec. You need to specify this with the -c option:
p4 -c <name-of-client-spec> changes -m1 <filepath>