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
Related
While testing my application using p4python I came across an intressting issue. I branch a while ago from a main stream directory to a testing directory, I did a revert on that branching since something was wrong with it so the testing branch disappeared (revert and submit). after fixing the issue, I decided to branch again with the same name but P4python said Can't populate target path when files already exist. That branch isn't there any more I don't understand why p4python would output such error. This is the code I use for branching:
result = p4.run("populate", path +"#"+ changelist, destination)
so my question is how to be able to branch again with the same name if the old branch wth that name is deleted?
The populate command only works for the specific case where you're creating a brand new branch; it doesn't handle any cases where you might potentially need to resolve the source against the target, so it will automatically fail if there are any files (even deleted ones) in the target.
If the branch was just for testing, you could obliterate it:
p4 obliterate -y destination/...
Or you could change your code to account for existing files:
p4.run("integrate", f"{path}#{changelist}", destination)
p4.run("resolve", "-as")
result = p4.run("submit", "-d",
f"integrated from {path}#{changelist} to {destination}")
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 am using following command to sync B vob files from A vob
clearfsimport -master -follow -nsetevent -comment $2 /vobs/A/xxx/*.h /vobs/B/xxx/
It works fine. But it will check in all the changes automatically. Is there a way to do the same task but leave the update files in a check out status?
I want to update the file for B from A. Build my programme, and then re-cover the branch. So if the updated files is an check out status, I can do unco later. Well with my command before, everything is checked in. I cann't re-cover my branch then.
Thanks.
As VonC said, it's impossible to prevent "clearfsimport" to do the check in. And he suggested to use a label to recover back.
For me, the branch where I did "clearfsimport" is branched from a label.Let's call it LABEL_01. So I guess I can use that label for recovery. Is there an easy way (one command) to recover the files under /vobs/B/xxx/ to label LABEL_01 ? I want to do it in my bash script, so the less/easy the command is, the better.
Thanks.
After having a look at the man page for clearfsimport, no, it isn't possible to prevent the checkins.
I would set a label before the clearfsimport, and modify the config spec for the new version to be created in a branch (similar to this config spec).
That way, "re-cover" the initial branch would be easy: none of the new version would have been created in it.
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.
Let there be:
There are different repositories repoA, repoB and repoC each respecting the same directory layout principles, which are to be merged onto a third repoM's working directory (the "master" project).
repoM has an atypical setup (--work-dir and --git-dir are sepparate). repo[A-C] are cloned as bare, and they are set as core.bare = false and core.worktree=<--work-dir-of-repoM>.
The requirements:
I need to always have an overview over the history of all files in repoM's work-dir, which could have stemmed from repo[A-C]. With this approach, I lose all that information.
Alternative:
I've been thinking about using git-subtree instead (git version 1.7.11.2, so it's already built-in), leaving repo[A-C] bare, and then
git pull -s subtree, or
git subtree ...
With the subtree pull strategy, I lose the history on a merge conflict (git blame says so).
I've never used subtree before, but from my understanding it's not possible to merge files from repo[A-C] into repoM's work-dir, those files must be put into a subdirectory of repo[A-C]. This is definitely not what I need. Why? Because of the following ...
Problem statement:
You have different git repositories each containing different sets of files, usually configuration files and some shell scripts. You want to put everything in the $HOME (which is <--work-dir-of-repoM>) directory from all those repositories. You should be able to see at all time where each file comes from, edit, commit and push changes to each one's origin. You've guessed it, it something like vundle, but generalized for any kind of configuration of any program, not just vim bundles. If a conflict occures, one should be able to track down which two authors of the same file need to get in touch with each other and make up a deal (if one needs to be made).
This is for an open-source project I'm trying to get a prototype working, so any help is highly appreciated. Also ideas about already existing projects which do this in a similar manner are highly appreciated.
Note: the "master directory" does not necessarily have to be $HOME, I've used it as a possible hint on the kind of problem this could solve.
Why not simply use Git Submodules in your "master project"?