I have setup some environment variables for my perforce, like P4PORT, it's working, I also export the P4PASSWD and can see it if I type $export -p, but the p4 still ask me to type in the password when I tried to log in with $ p4 -u myusername login. Any idea or solutions?
moreover, I noticed some comments within company's wiki, like "If you have automation that requires Perforce interaction and the requirements have not been communicated to the Perforce team, please send them an e-mail. Once the team becomes aware of all the details, Perforce tickets can be used to allow the automated interaction."
does that mean P4PASSWD is not allowed in my current repository and if I want to automate this, I need to use "perforce tickets" mechanism?
Thanks.
I did some research and seems got a valid solution, the solution is generating a global ticket, $ p4 login -a -p, this will print out a long string of characters, store it some where, for example, ~/.myp4ticket, then you can type $ p4 -P `cat ~/.myp4ticket` sync, cheers.
Related
Sorry i just updated my question.
Actually I'm working with 2 sites.
I have admin rights to the perforce server.
We are trying to design something that can integrate into a branch forcefully.
so we would like to make sure the destination branch does not have any opened files, by anyone, from any workspace, from any sites.
Is there a way for me to achieve that?
something like this?
p4 revert <some option> //depot/destination/branch/...
Thanks in advance.
As an admin it's possibly to forcefully revert files from the server side (i.e. make the server treat them as no longer open) with the -C flag (you may also need --remote in a DVCS configuration):
%p4 help revert
revert -- Discard changes from an opened file
...
The -C flag allows a user to specify the workspace that has the file
opened rather than defaulting to the current client workspace. When
this option is used, the '-k' flag is also enabled and the check for
matching user is disabled. The -C flag requires 'admin' access, which
is granted by 'p4 protect'.
The --remote flag is useful for DVCS configurations in which files
of type +l are in use. 'p4 revert --remote=origin filename' reverts
the named file in your DVCS server, and additionally, if the file is
of type +l, releases the global exclusive lock on the file in the
origin server.
This does not actually modify the files in the affected workspaces; those workspaces will therefore be in an inconsistent state, and may be at risk of losing changes if the user is not careful (i.e. their work in progress may be overwritten by a sync operation and/or missed by a submit).
I would recommend only doing the force revert if the files are locked; files that are opened but unlocked will not interfere with the integration, and reverting them will only make it more difficult for those users to reconcile their workspaces after the fact.
I don't have admin privileges. Need to test other's change lists and submit them.
Tried changing the owner of the CL but didn't work without admin.
p4 change -U <creator> <CL>
Error in change specification.
Change <CL> can only be updated by user <creator>
Unshelving the original CL, then testing it, will create a duplicate CL. Duplicate CL is submittable but not the original CL.
Are there any ways to submit a perforce change list of another user without admin privileges?
Based on documentation I'd say no (see below). The way you are doing it is probably the best way using shelving. Another option would be to have an unstable branch that code is okay to be broken and another user can 'release' after testing to a stable branch.
From my understanding, changelists are owned by the user and not really "transferable" like you want.
From Helix 2020.2 documentation on the p4 change command
The owner of an empty pending changelist (that is, a pending changelist without any files in it) can transfer ownership of the changelist to another existing user either by editing this field, or by using the -U user option.
If you start down the "sharing a workspace" path. Don't. "It is actively discourages by Perforce Technical Support" and "it is almost never a good idea to share a Perforce client workspace among multiple users" https://community.perforce.com/s/article/3675
When issuing a p4 command e.g. p4 client no matter current working directory is inside or outside the perforce workspace, the command output is
Error: p4 client root is not '/workspace_dir'.
Please make sure that your Perforce workspace has the 'Alt roots' set to '/workspace_dir'.
P4V client works ok.
How can change 'Alt roots' setting?
Run the p4 client command to edit your AltRoots.
If you do not have multiple client roots (which is a pretty rare situation), you do not need to set the AltRoots field. The error you quote is not a Perforce error that I'm familiar with and may be some sort of wrapper script or trigger that is configured to expect an AltRoot for reasons that may not be sound. I'd check with your Perforce admin for clarification.
I am trying to automate access to Perforce via it's command line utility.
Creating a new client workspace with p4 client and syncing works ok.
Now I am allowing users to overwrite user, host, port, stream, revision.
From the docs it is not clear to me when I have to execute which commands to get the client workspace files in sync with an edited client workspace spec.
What I currently do is once p4 client is through search for
Client mymachine not changed
in stdout and do a p4 sync -f should the message not appear.
Is there a better or more sane way to do this?
I tried executing e.g. p4 sync -s in hope that it would fail should local data be deleted but it seems that I misunderstood the option?
It is not clear to me how this relates to your question about workspaces:
Now I am allowing users to overwrite user, host, port, stream,
revision.
since only one of those is a property of a workspace. I'm going to disregard that statement for now but if it was significant I'd encourage you to post a follow-up clarifying what you mean by "overwriting" each of these properties.
To your question:
From the docs it is not clear to me when I have to execute which
commands to get the client workspace files in sync with an edited
client workspace spec.
If the client View is updated, all you need to do is:
p4 sync
If the client Root is updated, or any of the other options that globally affect how files are written to the workspace, such as allwrite or modtime, you will need to re-sync the entire client. Ideally this is done by doing:
p4 sync #none
prior to changing the workspace in one of these ways. The other option would be to do something like the following sequence:
p4 sync #none
p4 sync
p4 clean
to make sure that everything is rewritten, and that any stragglers (e.g. anything that the "sync #none" couldn't locate because the Root had changed but that are still mapped in the client view) are removed from the workspace.
I tried executing e.g. p4 sync -s in hope that it would fail should
local data be deleted but it seems that I misunderstood the option?
Deleting local data is a separate issue from editing the client spec, but for that the command you want is p4 clean rather than p4 sync -- you use sync to tell the server you want it to send you new revisions, you use clean to bring your workspace back in line with what the server already sent you.
The recommended/supported workflow is to always use p4 commands to manipulate the read-only files in your workspace -- so if you want to delete a local file, use either p4 sync FILE#none (to remove it from your workspace but not affect the depot) or p4 delete FILE (to open it for delete so that it will be deleted for everyone when you submit).
how to check if any changelist of project A is integrated in project B? and also to get corresponding submitted Cl in project B. Please share any perforce command
It's worth pointing out the unit of integration in P4 is files, not changelists, so the p4 commands are mostly focused around telling you which files are integrated or not. You can, however, find out which changelists still have some files that need to be integrated - use the p4 interchanges command. The Perforce docs explain the syntax.
Assuming that you have a branch spec that describes the relationship of project A and project B called projAprojB, then you can get the outstanding changelists with:
p4 interchanges -b projAprojB
You can also get a similar view of outstanding changes in the P4V Merge/Integrate dialog box.
Alternatively, you can use the 'revision graph' in P4V to see the integrations performed on a given file; doing this on a file from the changelist you want to know about will give you the information to work out if it has been integrated into the other project and the changelist for that was.
If this doesn't suit your needs then your only option is to write a script, either with shell scripting using p4 or one of the APIs provided by Perforce