Shelving operations in P4V

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.

Tagged : / / / /

Advantages of Git over SVN and perforce

What are the advantage of GIT over Subversion and perforce?

Code development has its negative and positive sides, but anything that brings more relief and gains time in a project is the developer’s best friend. CVS was for a long time the best solution for version control, adopted by all programmers in major projects. While CVS has slowly evolved into other more successful concurrent version systems like Subversion, the latest trend that manifests across the development world is the usage of DCVSs (distributed version control systems) as the main project tracking managers.

Since its launch in the mid ‘80’s and till 2000, CVS was the only real alternative as a revision control system for programmers. Not a very good one, but better than anything else. Built in 2000 by CollabNet Inc., Subversion was marketed from the start as “a better CVS” and “CVS done right.” It was truly better than CVS; unfortunately, it didn’t bring in that many new features, and under the hood, nothing has changed its core.

Because of that, there was a surge in revision control software development at the start of the 2000’s, which led to the birth and development of many DCVS projects. GNU arch and Monotone where about the first to be launched, followed by Darcs and BitKeeper.

A serious step in DVCS’ development took place after the quarrel between Linux developers and BitKeeper’s management, after BitKeeper accused one of the Linux developers of reverse engineering one of their commercially licensed features. Soon after, Linux programmers led by Linus Torvalds himself released Git as an improved open source solution to BitKeeper’s soft. Besides Git, Mercurial and Bazaar were also very successful alternatives to SVN, sharing many of Git’s features, but lagging in performance.

While SVN (Subversion) was extremely popular at the beginning, it established itself as the premiere solution in code development. Soon after, as DVCSs were developed and released, users migrated to them, abandoning SVN, opting for the more loose and faster solutions.

Nevertheless, old CVS users still tend to linger around SVN due to its familiar interface and old coding habits established over the years. Many of them question to this day Git’s efficiency in quickly putting versions together, while Git supporters, on the other hand, criticize SVN’s stiffness regarding offline work.

In many cases, the debate between Git and SVN supporters usually starts with the following features, or lack.

Git features

Offline work: Git permits any developer to branch a project and store it in a local folder as a standalone repository. After doing all the work offline, the central server or storage unit, they can than simply merge it with the central repository committing all the changes already made. This permits developers that don’t have Internet access all the time to work on a project with ease.

Central project information: Unlike SVN, which uses a .svn folder in each directory, Git uses a central .git folder in the checkout root for all project data and logs. This way, it’s easier to track changes to specific folders, on specific dates or by certain development teams. Thus, project code management is much more simplified. This also allows easy renaming of files or folders, Git automatically transmitting these changes in its history.

Easy branching: Branches and tags are much easier to create and switch in Git.

Merge history: While SVN has a branch merge history, it records all the events as coming from one user (the merger). In case a user has previously worked on a file and has not merged it, if that file is merged by another user, all the changes will be attributed to the user that merged the branch. Git, unlike SVN, can remember file changes beyond a merging point and track every user’s actions beyond project commits. Git also automatically starts the next merge at the last point it recorded.

Disk space: When the Mozilla project was ported from SVN to Mercurial (very similar to Git in performance), disk space usage went down from 12GB to 420MB, 30 times smaller than the original size. Git is supposed to use the same storage algorithms, so file size should be around the same value.

Speed: This is a no-brainer. Because all operations except for push or fetch are performed locally, Git’s speed is overwhelmingly faster than SVN could ever supply.

Better access and administration: SVN relies on an authentication module and access lists to permit users to push and merge branches. Git reduces the time spent for providing commit access to users and just lets the administration team decide what to merge and from whom.

Synchronization: It can occur over various types of media like an SSH channel, over FTP, HTTP, WebDAV, or by emails holding attached patches.

SVN features

GUI: From the beginning, SVN users have been using a GUI when managing their repository. This feature is not found at all in Git, a port for TortoiseSVN still being in the works. Besides the lack of a GUI, Git, coming from a UNIX environment, has a very complicated CLI interface with many options and arguments for its base commands.

Single major repository: Other may say this is not a good thing, but it’s a strictly SVN-specific feature. While Git allows each individual user to copy the entire repository on their computer and work on the project’s code, Subversion has always relied on permissions being given to users to only work on one single repository stored online. This feature allows the developer to always be able to download the latest version of their project without having to wait for all that work on the project to log online, upload and merge their latest branch. This is very useful in fast development environments or application troubleshooting.

Partial checkouts: Git doesn’t offer the possibility to download only a single folder from the repository. This may be a disadvantage to developers not having great bandwidth or speed.

Version numbers: Another keeper from the UNIX fathers of Git is the complicated version control numbers. While SVN uses a simple incremented decimal system, Git employs an SHA1 algorithm to output a 40-character hexadecimal string as the version number. This could get very tiring when having hundreds or more versions.

The abovementioned features are only a scratch on the surface when discussing about the version control system war between CVS/SVN supporters and DVCS users. More on the topic can be read here, which puts all the major platforms’ features next to one another so they can be compared.

Let’s now take a look at the parties involved and analyze their impact on the current programming and development world.

Subversion, as of 2009, was recently included in the Apache Incubator project, mainly because of its long usage history in most of the Apache Foundation’s projects. More details are available in one of my past articles on this topic. Other famous open source or commercial projects that have a weakness for SVN include market players like Ruby, Mono, Free Pascal, ExtJS, Tigris, PHP, MediaWiki, GCC, Django and FreeBSD. All having their source code administrated from an SVN repository.

On the other hand, the community’s favorite project, Git, is currently expanding its horizon every day, recently taking GNOME and The Perl Foundation away from SVN, placing them alongside other notable Git-powered projects like Android, Linux, openSUSE, Yahoo User Interface, x264, Digg, jQuery,, Samba, Ruby on Rails, CakePHP, Fedora, Merb, Freenet, GIMP, Parrot, Qt, rsync, Wine and VLC.

Other Git-like products like Mercurial (originally designed to replace BitKeeper for Linux development) have also been adopted by major corporations and programs like Mozilla, OpenJDK, OpenSolaris, Netbeans, OpenOffice, Vim, SAGE, Growl, Wget, Symbian OS and Adblock Plus. In 2010, The Python Foundation is going to join this list, migrating from SVN.

Another Git-like DVCS platform, generally regarded by the community as being slower than Git, but much easier to learn is Bazaar. This is a product developed especially for Ubuntu, but which saw adoption in many other projects around the web, some of them like Squid, APT, MySQL, GNU Emacs, Gnash and Inkscape.

The trend is easy to see. DVCSs are adopted in more and more projects, while SVN is headed for the history books alongside its precursor, CVS. The final battle in this version control systems war is being waged on the grounds of project storing platforms the likes of SourceForge, Google Code or CodePlex. The winner of this confrontation will surely decide whether SVN will be used in the coming future or whether it will fade away from our minds like the early PC consoles.

Currently, SourceForge and GNU Savannah have the biggest and widest hosting platforms, providing version control platforms like CVS, SVN, Git, Bazaar and Mercurial to all of their users free of charge. For SourceForge, by default, a project will be hosted on Subversion. The same happens in Google Code, where SVN is the default, but the Mountain View-based crew also provides Mercurial as a DVCS alternative. Renowned hosting platform, CodePlex, provides SVN, Mercurial and Microsoft TFS hosting, while the smaller service on Project Kenai offers SVN, Git and Mercurial.

Also lately, due to high technical costs, services are starting to opt only for one version control system, putting some heat in the discussions between the CVS communities. The list is as follows: Mercurial has exclusivity on Bitbucket, Bazaar on Launchpad; Git on Github, Codaset and Gitorious, and SVN on BountySource, Freepository, GridyZone and Origo. A slim crop for SVN, but being the default service on Google Code and SourceForge might give it a fighting chance against the up-and-coming Github.

Some of you might not agree with the previous claim that this is a “battle” and should not be at all compared with the browser wars, but the community deeply rooted in the tech world already knows this is more of a fact than a myth. As proof of concept, we bring you this video from a conference at Google back in 2007, where Linus Torvalds, the inventor of Linux and Git, made some outrageous statements regarding SVN, and especially its users.

If you don’t have the time to view this one-hour long video, we’ve listened to the conference and taken some interesting quotes from Mr. Torvalds: “Subversion has been the most pointless project ever started,” continuing with “Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do CVS right” and ending with “If you like using CVS, you should be in some kind of mental institution or somewhere else.”

Not very heart-warming comments from a public person like Linus Torvalds. Especially being made in the headquarters of one of the companies that have ignored Git and failed to include it in the Google Code project. Nevertheless, Mr. Torvalds might also be under the influence of an inner demon, specific to most UNIX users to prove that any project developed and coming from a Linux environment is better than anything else.

True or not, Git has seen a rise in usage, as proved by the 2008 and 2009 surveys, which had it ranked above any other versioning control platform like SVN, Bazaar and Mercurial, and with a crushing 94.6% rate of overall satisfaction toward the Git user experience. As a conclusion, it is generally acknowledged that future versions of Git will be adopted in more and more environments, and Git will have to fight only against other DVCSs for supremacy in the programming world.

One more good link for Advantahe of git over SVN(Subversion) …

Tagged : / / / / / / / / /

Perforce Central Authorization Server: P4AUTH

Perforce Central Authorization Server: P4AUTH

Author: Rajesh Kumar
Email Id:


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

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:

Command Forwarded? Notes
p4 group Yes Local group data is derived from the central server.
p4 groups Yes Local group data is derived from the central server.
p4 passwd Yes Password settings are stored on, and must meet the security level requirements of?, the central server.
p4 review No Service user (or remote) must have access to the central server.
p4 reviews No Service user (or remote) must have access to the central server.
p4 user Yes Local user data is derived from the central server.
p4 users Yes Local user data is derived from the central server.
p4 protect No The local server’s protections table is displayed if the user is authorized (as defined by the combined protection tables) to edit it.
p4 protects Yes Protections are derived from the central server’s protection table as appended to the outer server’s protection table.
p4 login Yes Command is forwarded to the central server for ticket generation.
p4 logout Yes Command is forwarded to the central server for ticket invalidation.

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


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:


For more info.

Tagged : / / / / / / /

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.

  • Rajesh Kumar

    Rajesh Kumar 

    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?

  • mfeighner


    Yes, that would be in order.  I posted here only because that is where I was invited.

  • Rajesh Kumar

    Rajesh Kumar 

    Hi mfeighner,

    its been long time to see you post here. Hows life going on? Where you have joined recently?

Tagged : / / / / /

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: 
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:

The following settings can be specified in a config file.

Setting Description
P4CLIENT Name of the current client workspace.
P4EDITOR The editor invoked by those Perforce commands that use forms.
P4HOST Hostname of the client workstation. Only useful if the Host: field of the current client workspace has been set in the p4 client form.
P4PASSWD Supplies the current Perforce user’s password for any Perforce client command.
P4PORT The host and port number of the Perforce server or proxy with which to communicate.
P4USER Current Perforce user name.

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:

She creates a second .p4config file in/home/rama/p4-ona. It contains the following text:

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

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



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.

To specify server settings on the command line, use the -p flag. For example:
p4 -p localhost:1776 sync //depot/dev/main/jam/Jambase


Tagged : / / /

Perforce Customization To Revert Changelist

Perforce Customization To Revert Changelist

Attachech Python File: Download here Perforce Python script to revert Changelist


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

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 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. (

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 : -c <Client> -p <Port> -u <User> <ChangeList>

Example: -c Mramchandran -p -u jayesh 163806

This is not tested. It is also convenient to use through perforce.


1.If my Revert ChangeList contains file say and that file is also part of another change list in the client machine. Then the file 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.

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.



Contributed Made by: Ramchandran M

Tagged : / / / /

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.

Tagged : / / /

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


-c client
Overrides any P4CLIENT setting with the specified client name.
-d dir
Overrides any PWD setting (i.e. current working directory) and replaces it with the specified directory.
Causes all output (and batch input for form commands with -i) to be formatted as marshalled Python dictionary objects. This is most often used when scripting.
-H host
Overrides any P4HOST setting and replaces it with the specified hostname.
-p port
Overrides any P4PORT setting with the specified port number.
-P pass
Overrides any P4PASSWD setting with the specified password.
Prepends a descriptive field (for example, text:, info:, error:, exit:) to each line of output produced by a Perforce command. This is most often used when scripting.
-u user
Overrides any P4USER, USER, or USERNAME setting with the specified user name.
-x file
Instructs Perforce to read arguments, one per line, from the specified file. If file is a single hyphen (-), then standard input is read.
-C charset
Overrides any P4CHARSET setting with the specified character set.
-Q charset
Overrides any P4COMMANDCHARSET setting with the specified character set.
-L language
This feature is reserved for system integrators.
-z tag
Causes output of many reporting commands to be in the same tagged format as that generated by p4 fstat.
Displays the version of the p4 client program and exits.
Displays basic usage information and exits.


Usage Notes
Be aware that the global options must be specified on the command line before the Perforce command. Options specified after the Perforce command will not be interpreted as global options, but as options for the command being invoked. It is therefore possible to have the same command line option appearing twice in the same command, being interpreted differently each time.
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 is useful for automating tedious tasks; a user adding several files at once could create a text file with the names of these files and invoke p4 -x textfile add to add them all at once.
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.
The -s option can be useful in automated scripts.
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:”.
Python developers will find the -G option extremely useful for scripting. For instance, to get a dictionary of all fields of a job whose ID is known, use the following:
job_dict = marshal.load(os.popen(‘p4 -G job -o ‘ + job_id, ‘rb’))
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:
Tagged : / / / / /