I want to create a p4 branch based on branch mvs_1211_hf at this label CC2P4_MVS_1211_HF_PILOT1, but the p4 command response is not my expectation. Anyone can help on this? Or is there any ways to create branch in p4? Thanks in advance!
Here is the p4 command i run:
p4 integ //depot/MVS_IMPORT/mvs_1211_hf/tms_dev/...#CC2P4_MVS_1211_HF_PILOT1 //deport/1211_hf/...
Here is the p4 complains:
//deport/1211_hf/... - must refer to client 'ruilong_mvs_1211_hf_pilot1'.
Best regards,
Ruilong
Typical errors include the ones previously mentioned, plus:
//depot1/... - must refer to client 'clientname'.
Check the client workspace view by running:
p4 client -o clientname
Check the "View" lines in the client workspace specification to confirm that the file specification used in your Perforce command (or appearing in the error message) falls within your workspace view.
If needed, change the client workspace by running:
p4 client clientname
Find more at: http://answers.perforce.com/articles/KB_Article/Common-Permissions-and-File-Access-Problems
Thanks
I received this error, when the path simply did not exists... had a typo :/
The must refer to client <client> error is the generic error given when an absolute path is neither a valid depot path nor a valid client path within the context of the current client. In this case, the cause of the error is that you typed //deport instead of //depot.
It would be more accurate for the error to say must be a depot path or a client path referring to current client <client>, but Perforce error messages tend to err on the side of brevity.
Related
I am facing a weird behavior in perforce submitted files, after p4 integrate
Scenario
Repo contains C# code and the built DLL. I wished to integrate a changeset from one branch to another
so I am following the steps which I had discussed, a while ago
The .cs files doesn't complain. If there is resolve conflict in the DLL, I choose either of Accept Source or Accept Target without much care. Reason being, I always rebuild the DLL before submitting
Issue
The DLL which was built in local workspace and reflected in the changeset is correct. I tested it locally and do p4 submit. But to my amazement, the DLL submitted is not the one which I had built. Instead the one which came from that other branch was submitted
Confusion
I thought that with perforce, when a file is opened in a changeset, always the latest(local) copy will be submitted. That is why I don't pay much attention if there are conflict reported in DLL
Isn't that correct ?
Why would the submitted file be different from my workspace version ?
When you "accept source" you're recording that you want the target file to be an exact copy of the source file; consequently, if you submit the file, it's not even transferred from the workspace (in order to save time) -- instead it's just copied server-side. If you tampered with the workspace file, this leads to the situation you describe where the workspace is now inconsistent with the depot, just like if you'd modified a file that wasn't open for edit.
If you submit with the -t flag (for "tamper checking"), it will check for tampered files by comparing what's in your workspace with what should be in your workspace according to the resolve options you picked:
C:\Perforce\test\integ>p4 integ source target
//depot/integ/target#2 - integrate from //depot/integ/source#3
C:\Perforce\test\integ>p4 resolve -at
c:\Perforce\test\integ\target - vs //depot/integ/source#3
//Samwise-dvcs-1509687817/integ/target - copy from //depot/integ/source
C:\Perforce\test\integ>echo tampertampertamper >> target
C:\Perforce\test\integ>p4 submit -t -d "submitting tampered file"
Submitting change 190.
Locking 1 files ...
integrate //depot/integ/target#3
//Samwise-dvcs-1509687817/integ/target tampered with after resolve - edit or revert.
Submit aborted -- fix problems then use 'p4 submit -c 190'.
Some file(s) could not be transferred from client.
If you p4 edit the file, it's changed from a pure copy to an edit, and will be read from the workspace instead of from the source file:
C:\Perforce\test\integ>p4 edit target
//depot/integ/target#2 - reopened for edit
C:\Perforce\test\integ>p4 submit -c 190
Submitting change 190.
edit //depot/integ/target#3
Change 190 submitted.
I tried to add a new file using
sd add myfile.txt
But I get this error saying
myfile.txt - file(s) not in client view.
Can you please tell me how can I fix it?
The general answer is that you need to edit the client view and/or root ("sd client") so that your local "myfile.txt" is mapped to the depot.
For a more specific answer I'd need to know:
The full local path of myfile.txt
The full depot path you want to add it to
I'm running p4 interchanges -b my_branch, and I get a ton of results, the first one being a changelist that we integrated a long time ago.
So I try to integrate again, but p4 integrate -b my_branch //...#changelist,#changelist just returns "All revision(s) already integrated".
The only way to unblock this is to do a forced integration (-f in the integrate command) and then simply accept target (-at when resolving), and that works - p4 interchanges then no longer lists this changelist.
But how can Perforce get into this state to begin with? This happened after we've done a bunch of integrating across multiple branches, but I nothing that I'd think would cause a changelist to become "unintegrated" somehow.
This is on a 2014.1 server.
Thank you for specifying your server version.
The 'p4 interchanges' command can give the "All revision(s) already integrated" message with misleading results when cherry-picking is involved.
There is a command line example here:
http://answers.perforce.com/articles/KB_Article/Cherry-Picking-Integrations
You could also be affected by a bug that was patched in 2014.1 listed here in the server release notes:
http://www.perforce.com/perforce/doc.current/user/relnotes.txt
Bugs fixed in 2014.1 PATCH5
#880506 (Bug #71725) **
The istat.mimic.ichanges configurable controls the reporting
of revisions between stream and parent. If set, istat will
not report cherry-picked revisions already present in the target.
The default behavior will report any changes not credited, even
when the content may already be in the target.
If you would like, you can pull the most recent build of the server P4D for your OS from our ftp site: http://ftp.perforce.com/perforce/r14.1/
REFERENCE
http://answers.perforce.com/articles/KB_Article/Integration-Changes-Reporting
I'm seeking assistance to determine max changeListId/revisionId of the my local Perforce view using the p4java API. I've tries using the com.perforce.p4java.client.Client to create a list of FileSpec, but changeListId is not set on any of the files when querying the Client - Server is OK.
I am seeking the client's current revision number to help me determine if it is in synch with the server or not. Details such as this sample from 'p4 cstat' would be perfect:
p4 cstat
... change 1
... status have
......
... change 17
... status partial
... change 18
... status need
p4java p4java version 2012.3
Thanks in advance!
A common way to do this is to use "p4 changes -m q ///...#have". With P4Java you would use the GetChangelists() method on IOptionsServer with the appropriate filespec and version specifier.
I'm new to Perforce, and it is not going well at all. But currently, I am completely stuck, as all I can get it to say is:
$ p4 open a_code_file.cpp
Locked client 'my_hostname' can only be used by owner 'perforce'.
I have absolutely no idea what I did to upset it, and the error message itself is meaningless gibberish to me. "perforce" doesn't own anything - all the files are owned by me. I am in a Perforce repository, ie, there's a .p4rc a few directories up.
Edit: It only seems to be some files. If I:
$ cd some_other_directory_in_the_repo
$ p4 open a_file
... it works. So it's only some things...
The "locked client" error suggests that p4 is trying to use a client workspace, named after your hostname, owned by the user perforce. If Perforce can't find a valid client name, either in the registry (on Windows), environment variables, or in an environment file, it'll default to using a client workspace named after your hostname.
It sounds like Perforce can't find a valid client workspace for your "broken" directory, and finds one for your "working" directory.
Since you have one directory that works, and one directory that doesn't, can you try:
$ p4 set
from both directories, and compare the results? If Perforce can find a valid client, you'll see something like:
P4CLIENT=XXXX (config)
(the "(config)" means Perforce is getting that configuration variable from a configuration file. Consult p4 help set for more information on the various ways you can set variables.)
Look also for a line like:
P4CONFIG=.p4env
which is what Perforce will use to search for your workspace configuration. If you're using a file named .p4rc, that's what P4CONFIG should be set to.
I ran into this when I was distracted and forgot to export my P4CLIENT variable, i.e.:
P4CLIENT=XXXXX
Instead of:
export P4CLIENT=XXXXX