I found very good feature in perforce about Shelving operations in P4V. This is something id deport is not ready to check in the src code due to release or code freeze, still you can store changes in depot without check in.
Category: Perforce
Perforce
Perforce Customization To Revert Changelist
Perforce Customization To Revert Changelist
Perforce Customization To Revert Changelist
Perforce Central Authorization Server: P4AUTH
Perforce Central Authorization Server: P4AUTH
Author: Rajesh Kumar
Email Id: rajesh@scmGalaxy.com
Contents
Problem Statement:
Solution: P4Auth
Advantage of Perforce centralized authorization server
Overview of P4Auth
How to Implement?
Verification: centralized authorization server
Configure outer server to listen central authorization server
Commands to the central server
Limitations and notes
FAQ
Reference:
Problem Statement:
Prepare a report on Perforce Servers Automation which consists of following requirement.
We need to develop a centralized web based tool which will control and manage all the perforce Servers instance and Minimize the time spending on admin work related to following…
1. User Creation /Deletion
2. Group Creation / Deletion
3. Assigning Depot Access to group such as modifying protect table
Solution: P4Auth
The feature (centralised server) you are looking for has been available Undocumented for several years. However since the 2010.2 release, it is now fully supported and documented.
In multiple perforce Server scenario, we can configure them to retrieve protections and licensing data from a centralized authorization server.
Advantage of Perforce centralized authorization server
- By using a centralized server, we are freed from the necessity of ensuring that all your servers contain the same users and protections entries.
- If a user does not exist on the central authorization server, that user does not appear to exist on the outer server.
- If a user exists on both the central authorization server and the outer server, the most permissive protections of the two lines of the protections table are assigned to the user.
- We can use any existing Perforce Server in your organization as your central authorization server.
- The license file for the central authorization server must be valid, as it governs the number of licensed users that are permitted to exist on outer servers.
Overview of P4Auth
- Allow multiple edge servers to authenticate off a central server.
- Introduced in 2002.2. However since the 2010.2 release, it is now fully supported and documented.
- Undocumented and officially unsupported till 2010.1
- See ‘p4 help undoc’ for documentation.
- Shares protections, groups, users, and passwords with the central server.
- Servers need constant access to the central server. If the network connection is down no commands can be authenticated.
How to Implement?
To configure a Perforce Server to use a central authorization server, set P4AUTH before starting the server, or specify it on the command line when you start the server. Setting P4AUTH by means of a p4 configure set P4AUTH=server:port command takes effect immediately.
- Pass -a to p4d at startup point to the central server or set P4AUTH=<ip:port> and restart the server.
- Protections table entries that use IPs need to be Prefixed with proxy- for clients connecting through edge servers.
- The user ‘remote’ account needs to be configured on the central auth servers.
Verification: centralized authorization server
If your server is making use of a centralized authorization server, the following line will appear in the output of p4 info:
Authorization Server: host:port
Where host:port refer to the host and port number of the central authorization server.
Configure outer server to listen central authorization server
In the following example, an outer server (named server2) is configured to use a central authorization server (named central). The outer server listens for user requests on port 1999 and relies on the central server’s data for user, group, protection, review, and licensing information. It also joins the protection table from the server at central:1666 to its own protections table.
For example:
p4d -In server2 -a central:1666 -p 1999
Commands to the central server
Central authorization server, outer servers forward the following commands to the central server for processing:
Limitations and notes
- All servers that use P4AUTH must have the same unicode setting as the central authorization server.
- Setting P4AUTH by means of a p4 configure set P4AUTH=server:port command takes effect immediately. You do not have to stop and restart the outer server.
- To ensure that p4 review and p4 reviews work correctly, you must enable remote depot access for the service user (or, if no service user is specified, for a user named remote) on the central server.
- To ensure that the central server correctly distinguishes forwarded commands from commands issued by trusted, directly-connected clients, you must define any IP-based protection entries by prepending the string “proxy-” to the IP address.
- Protections for non-forwarded commands are enforced by the outer server and use the plain client IP address, even if the protections are derived from lines in the central server’s protections table
FAQ
When we create Centralized Authorization server, how does it impact on performance, considering perforce servers are located in multi-site location such as India-USA-Canada-Australia etc etc?
High latency network between the centralised server and outer servers may have Some performance impact. Perforce team have not conducted any performance Benchmark test for this. We need to look into this and find out feasible solution for this.
Many commands such as group, groups, passwd, review, reviews, user, users, protect, protects, login, logout is hitting to central server, Does it create huge process queue in central perforce server imagining min. 500 user is using these commands in one point of time? How this will be tackled?
Perforce is able to handle a large number of requests. Therefore from a performance point of view, the bottleneck will be the centralised server hardware. As I mentioned, some customers have been using centralised servers for many years and I am not aware of anyone having significant performance problem because of this feature.
Can I imagine a web based tool which can administer 100’s of perforce server instance and where employee can browse all listed depot and if they need access (read/Write/Super) on any depot/branch/codeline, they can raise a request through given interface in web tool and this request directly goes to admin(Super) of that particular Server Instance in form of an email, and he can reject/approve this access. As soon as he accept the request, new access definition should be added in perforce protection table?
This is not something you can have “out of the box” but this is certainly something that you should be able to implement using our p4php and p4perl api:
Reference:
http://www.perforce.com/perforce/r10.2/manuals/p4sag/03_superuser.html#1093172
http://www.perforce.com/perforce/r10.2/manuals/cmdref/env.P4AUTH.html
For more info.
http://www.scmgalaxy.com/forum/perforce/
Thanks for the Invitation to the PerForce Group
Thanks for the Invitation to the PerForce Group.
Thanks for the Invitation to the PerForce Group.
However, I have no idea what to discuss here as I have never used PerForce and doubt very much I ever will. After 10 years of experience with ClearCase and ClearQuest, I have been unemployed for 18 months now, and my COBRA ends this Friday, May 6th. I got very tired of applying for jobs where I have been run over by the technology revolution. I am also tired of recruiters who contact me and do not do their homework. They are wasting their time, mine. and that of the hiring manager. For that reason I needed to look outside the box and am now undergoing PMP training. Later I will be taking the PMP Certification Exan.
How to Setup p4 in Linux / Unix
How to Setup p4 in Linux / Unix
Well many people have these questions to me that they are facing issues setting up p4 client in Linux or Unix. The Solution is pretty much straight forwards but sometimes we miss some of things which delay the setup process.
Here I have tried to points out these already available on Perforce Knowledge base site.
Download and Installations:
| 1. | Download the p4 executable file from the Perforce web site: |
http://www.perforce.com/perforce/downloads/index.html
The Perforce client programs are typically downloaded to /usr/local/bin.
| 2. | Make the p4 file executable (chmod +x p4) |
Perforce Configuration and Workspace Setting
Method 1
Using Config Files:
Config files are text files containing Perforce settings that are in effect for files in and below the directory where the config file resides. Config files are useful if you have multiple client workspaces on the same machine. By specifying the settings in config files, you avoid the inconvenience of changing system settings every time you want to work with a different work-space.
To use config files, you define the P4CONFIG environment variable, specifying a file name (for example, .p4config). When you issue a command, Perforce searches the current working directory and its parent directories for the specified file and uses the settings it contains (unless the settings are overridden by command-line flags).
P4CONFIG = .p4config
Each setting in the file must be specified on its own line, using the following format:
setting=value
The following settings can be specified in a config file.
For details about these settings, refer to the Perforce Command Reference.
Example: Using config files to handle switching between two workspaces
Ona switches between two workspaces on the same machine. The first workspace is ona-ash. It has a client root of /tmp/user/ona and connects to the Perforce server at ida:1818. The second workspace is called ona-agave. Its client root is /home/ona/p4-ona, and it uses the Perforce server at warhol:1666.
Rama sets the P4CONFIG environment variable to .p4config. She creates a file called .p4config in /tmp/user/rama containing the following text:
P4PORT=ida:1818
P4CLIENT=ona-ash
She creates a second .p4config file in/home/rama/p4-ona. It contains the following text:
P4PORT=warhol:1666
P4CLIENT=ona-agave
Any work she does on files under /tmp/user/rama is managed by the Perforce server at ida:1818 and work she does on files under /home/rama/p4-ona is managed by the Perforce server at warhol:1666.
Method 2: Environment Variable Setting
To configure server connection settings using environment variables, set P4PORT to host:port, as in the following examples.
| If the server is running on | and is listening to port | set P4PORT to |
| your computer | 1666 | localhost:1666 |
| perforce | 1666 | 1666 |
Example:
export P4PORT=X.X.X.X\:1667
export P4PASSWD=pass
export P4USER=user
export P4CLIENT=Sonar
export PATH
Defining client workspaces
To define a client workspace:
| 1. | Specify the workspace name by setting P4CLIENT; for example, on a UNIX system: |
$ P4CLIENT=bruno_ws ; export P4CLIENT
|
2. |
Issue the p4 client command. |
Perforce displays the client specification form in your text editor.
| 3. | Specify (at least the minimum) settings and save the specification. |
The minimum settings you must specify to configure a client workspace are:
|
• |
Workspace name |
The workspace name defaults to the client machine’s hostname, but a client machine can contain multiple workspaces. To specify the effective workspace, set P4CLIENT.
| • | Client root |
The client root is the top directory of your client workspace, where Perforce stores your working copies of depot files. Be sure to set the client root, or you might inadvertently sync files to your client machine’s root directory.
Note:
To specify server settings on the command line, use the -p flag. For example:
p4 -p localhost:1776 sync //depot/dev/main/jam/Jambase
Reference:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/02_config.html#1069873
http://www.perforce.com/perforce/doc.current/manuals/p4guide/02_config.html#1071378
http://www.perforce.com/perforce/doc.current/manuals/p4guide/01_install.html#1070774
Perforce Customization To Revert Changelist
Perforce Customization To Revert Changelist
Attachech Python File: Download here Perforce Python script to revert Changelist
Purpose
In Perforce if we check in any change list and in case if we want to revert the change list. Perforce does not have feature to Revert Change List.
We have to do it manually by using following steps.
1) Take a change list version which is predecessor of the current one which we want to revert
2) Do head sync to that change list revision.
3) Check out the files which we want to revert. Resolve them and check in
But we can very well eliminate the above three manual steps and automate the process of Reverting Change list by Customizing Perforce to have Revert Change List Feature.
This feature will be very useful if the Changelist which we want to revert have large number of files
Risk
There is no Risk with this feature because the changelist which we revert are not directly submitted. When we do a Revert Change List a new Change List will be created and we have the capability to resolve the conflict if there are more than one Revision for that file.
Required Software Version
Download Recent version of Python from http://www.python.org/download/ and Install Python and set the path for library files of python in the environment variables just like java.
Software Program Required for Customization
I have downloaded Python Program from the following URL which will help in Reverting Change List. (http://www.tilander.org/aurora/2007/06/reverting-a-perforce-changelis.html).
Perforce Client Side Changes for Customization
Following Customization needs to be done to add Revert ChangeList option in perforce.
1. Open Perforce
2. Go to Tools >> Customize
3. Click Add Button
4. Enter Name as RevertChangeList, Give the location of the Python Program
5. Give the argument as -c $c -p $p -u $u %c
C – Client
P – Port Number
U –User
Note : Make sure “Close window upon exit” is not checked initially for the first time. So that we can see the success message in console.
In case if it is checked. If the Python Program fails. Then we may not be able to see the message.
6. Once this is done then Click View Submitted Change List. Right click the change list which you want to revert and click RevertChangeList.
7. Once this is done all the files that were reverted will be available under Default Changelist.
8. Create New Changelist and move all from Default Changelist.
9. Check the whether they are reverted properly. If there are some version conflict then resolve them and checkin.
10. Using this feature I had reverted changelist Number : 163806
11. Outside Perforce also this utility can be run. We can also run the utility from windows prompt by giving following command
Command :
p4revert.py -c <Client> -p <Port> -u <User> <ChangeList>
Example:
p4revert.py -c Mramchandran -p 10.10.50.201:1666 -u jayesh 163806
This is not tested. It is also convenient to use through perforce.
Troubleshooting
1.If my Revert ChangeList contains file say A.java and that file is also part of another change list in the client machine. Then the file A.java will not be reverted.
2. Always check the number of files that are present in the changelist is same as same number of files that are present in the new change list once RevertChangeList is done.
Limitations
1. The only limitation this tool has is the Revert ChangeList customization is written in Python. It will be good if we can understand the logic and convert to Java.
References
1. http://www.tilander.org/aurora/2007/06/reverting-a-perforce-changelis.html
2. http://kb.perforce.com/?article=014
3. http://www.python.org/download/
Contributed Made by: Ramchandran M
Ways to Pass Password in Triggers file or Script file in Perforce
Option 1
If your Perforce server is set to security level 2 or lower you can have your trigger script run as the same user every time (typically a “background” user). Then, either have the server’s P4PASSWD environment variable set to the background user’s password,
Option 2
You can also use the -P flag to specify the password with the P4 commands issued by the script.
Option 3
You can echo the password and pipe it to the login command. Note that there is no space between the password and the pipe symbol.
echo <password>| p4 login
Option 4
If you do not want to place a password in the script, you can use a text file containing the password. Make sure this password file has appropriate read and write privileges.
p4 login < password.txt
Option 5
A more secure method is to use ticket based authentication and a group to keep a background user “logged in” at the Perforce server:
1. Create a group:
p4 group always_on
2. Add your background user to the “Users” field.
3. Change the timeout from the default setting (12 hours), which is set in seconds. The new value depends on the server version:
# 2008.1 and later: Set this value to “unlimited”. A timeout value of zero is no longer accepted.
# 2005.1 to 2007.3: Set this value to zero.
# 2004.2 and earlier: Set this to a very large value — but not too large, as some server versions do not handle situations where the timeout is set to exceed the “Unix Epoch”, which is approximately in the year 2038. A safe value is 315532800 seconds, which is about 10 years.
# Save the group.
# In your trigger script, log the background user in and run the trigger once.
echo password| p4 -p server:port -u username login
# If the trigger runs properly, you can remove the password line.
The user now remains logged in. Since this is ticket based authentication, they remain logged in even if the server is shut down or the hardware is rebooted.
Perforce Command Line Global Options
<!– .style1 { font-size: 24px; font-weight: bold; } –>
Perforce Command Line Global Options
Global options for Perforce commands; these options can be supplied on the command line before any Perforce command.
p4 [-cclient -ddir -Hhost -pport -Ppass -uuser -xfile -Ccharset -Qcharset -Llanguage] [-G] [-s] [-z tag] cmd [args …]
p4 -V
p4 -h
p4 -V
p4 -h
|
Overrides any P4CLIENT setting with the specified client name.
|
|
|
Overrides any PWD setting (i.e. current working directory) and replaces it with the specified directory.
|
|
|
Overrides any P4HOST setting and replaces it with the specified hostname.
|
|
|
Overrides any P4PORT setting with the specified port number.
|
|
|
Overrides any P4PASSWD setting with the specified password.
|
|
|
Overrides any P4USER, USER, or USERNAME setting with the specified user name.
|
|
|
Overrides any P4CHARSET setting with the specified character set.
|
|
|
Overrides any P4COMMANDCHARSET setting with the specified character set.
|
|
|
Causes output of many reporting commands to be in the same tagged format as that generated by p4 fstat.
|
|
For example, the command p4 -c anotherclient edit -c 140 file.c will open file file.c for edit in pending changelist 140 under client workspace anotherclient.
|
•
|
The -x option can be extremely powerful – as powerful as whatever generates its input. For example, a UNIX developer wishing to edit any file referring to an included file.h file, for instance, could grep -l file.h *.c | cut -f1 -d: | p4 -x – edit.
In this example, the grep command lists occurrences of file.h in the *.c files, the -l option tells grep to list each file only once, and the cut command splits off the filename from grep’s output before passing it to the p4 -x command.
For example, a script could be written as part of an in-house build process which executes p4 -s commands, discards any output lines beginning with “info:”, and alerts the user if any output lines begin with “error:”.
|
•
|
In some cases, it may not be intuitively obvious what keys are used by the client program. If you pipe the output of any p4 -G invocation to the following script, you will see every record printed out in key/value pairs:
Perforce Command Line
Command |
Description |
|
|
p4 add
|
Open file(s) in a client workspace for addition to the depot. | |
|
p4 admin
|
Perform administrative operations on the server. | |
|
p4 branch
|
Create or edit a branch specification and its view. | |
|
p4 change
|
Create or edit a changelist specification. | |
|
p4 changelists
|
List submitted and pending changelists. | |
|
p4 changelist
|
Create or edit a changelist specification. | |
|
p4 client
|
Create or edit a client workspace specification and its view. | |
|
p4 clients
|
List all client workspaces currently known to the system. | |
|
p4 delete
|
Open file(s) in a client workspace for deletion from the depot. | |
|
p4 depot
|
Create or edit a depot specification. | |
|
p4 depots
|
Display a list of depots known to the Perforce server. | |
|
p4 describe
|
Provides information about changelists and the changelists’ files. | |
|
p4 groups
|
List groups of users. | |
|
p4 group
|
Add or delete users from a group, or set the maxresults, maxscanrows, and timeout limits for the members of a group. | |
|
p4 have
|
List files and revisions that have been synced to the client workspace | |
|
p4 info
|
Display information about the current client and server. | |
|
p4 integrate
|
Open files for branching or merging. | |
|
p4 integrated
|
Show integrations that have been submitted. | |
|
p4 job
|
Create or edit a defect, enhancement request, or other job specification. | |
|
p4 jobs
|
List jobs known to the Perforce server. | |
|
p4 label
|
Create or edit a label specification and its view. | |
|
p4 labels
|
Display list of defined labels. | |
|
p4 lock
|
Lock an opened file against changelist submission. | |
|
p4 login
|
Log in to a Perforce server by obtaining a ticket. | |
|
p4 logout
|
Log out of a Perforce server by removing or invalidating a ticket. | |
|
p4 passwd
|
Change a user’s Perforce password on the server. | |
|
p4 rename
|
Renaming files under Perforce. | |
|
p4 resolve
|
Resolve conflicts between file revisions. | |
|
p4 revert
|
Discard changes made to open files. | |
|
p4 set
|
Set Perforce variables in the Windows registry. | |
|
p4 submit
|
Send changes made to open files to the depot. | |
|
p4 sync
|
Copy files from the depot into the workspace. | |
|
p4 tag
|
Tag files with a label. | |
|
p4 triggers
|
Edit a list of scripts to be run conditionally whenever changelists are submitted, forms are updated, or when integrating Perforce with external authentication mechanisms. | |
|
p4 user
|
Create or edit Perforce user specifications and preferences. | |
|
p4 users
|
Print a list of all known users of the current server. | |
|
p4 verify
|
Verify that the server archives are intact. | |
|
p4 workspace
|
Create or edit a client workspace specification and its view. |
Thats good news indeed that you are going through PMP certification.
However, I guess this discussion can be made on group Discussion place instead of blog place.
What you say?
Yes, that would be in order. I posted here only because that is where I was invited.
Hi mfeighner,
its been long time to see you post here. Hows life going on? Where you have joined recently?
cool:)