Under most circumstances, your Perforce server’s P4PORT setting consists of a port number. Users must know the IP address (or be able to resolve it from a hostname) of the Perforce server in order to connect to it.

The value of P4PORT however, can also include an IP address or hostname that resolves to an IP address. You can set P4PORT to configure the following possibilities:

P4PORT might also specify a protocol (protocol:address:port), which further restricts possible connections to those using the specified protocol. For complete information, see the description of the P4PORT variable in the P4 Command Reference.

The Perforce versioning service offers a mechanism to control which revisions of client applications are able to connect to Perforce.

To require a minimum revision, set the configurables minClient to the appropriate revision, and (optionally) set minClientMessage to the error message displayed when users of older applications connect to the server.

For example:

$ p4 configure set minClient=2010.2
$ p4 configure set minClientMessage="Please upgrade to 2010.2 or higher"

You can set the rejectList configurable to block one or more client programs from accessing the Perforce server. By default, all clients may access the server.

The simple version of the syntax for setting rejectList is the following:

rejectList = progName [[,progName]...]

The syntax of progName is the following:

progName[,version=versionName]

For example, the following command blocks requests from all command line clients.

$ p4 configure set "rejectList = p4"

The following command blocks requests from command line clients version 13.1 and 13.2.

$ p4 configure set "rejectList = p4, version=13.1, p4, version=13.2"

You may not use any wild card character in the program name parameter.

The comma is used as the default separator for the elements in rejectList. If the version number for the program you are excluding includes a comma, you must use a slightly more complicated syntax to define rejectList:

rejectList = separator=char  progName [[char progName]...]

If you define char to be #, the previous command line would look like this:

$ p4 configure set "rejectList = separator=# p4, version=13,1# p4# version=13,2"

The rejected connection is never logged; the log will not include information about the connection attempt.

You can specify a version using a build number; for example:

$ p4 configure set "rejectList = p4, version=1221235"

Or you can use platform information; for example:

$ p4 configure set "rejectList = p4, version=DARWIN90X86_64"

Or you can block for either condition; for example:

$ p4 configure set "rejectList = p4, version=1221235, p4, version=DARWIN90X86_64"

Note the use of quotation marks for strings that include spaces!

$ p4d -r P4ROOT '-cunset rejectList'

P4V users have the option of enabling user metrics collection. By default no data is collected. The first time a user connects to the server, a prompt is displayed asking if the user wants to send Perforce anonymous user data. Such data includes information about system hardware, non-default user preferences, and so on. The user can subsequently change collection preference using the Preferences menu.

If you do not want users to see the prompt, you can set a property on the server as follows:

$ p4 property -a -n P4.DataAnalyticsPrompt -v off

This prevents the user from seeing the prompt. However, this is an incomplete solution, because if the user connects to a server that does not have the property set, they will see the prompt and might choose to send the data. To fully disable this feature, you will need to have IT shut down any outgoing POST requests to udc.perforce.com.

If your Perforce server is on UNIX, and you have users on both UNIX and Windows, your UNIX users must be very careful not to submit files whose names differ only by case. Although the UNIX server can support these files, when Windows users sync their workspaces, they’ll find files overwriting each other.

Conversely, Windows users will have to be careful to use case consistently in filenames and pathnames when adding new files. They might not realize that files added as //depot/main/one.c and //depot/MAIN/two.c will appear in two different directories when synced to a UNIX user’s workspace.

The UNIX Perforce server always respects case in client names, label names, branch view names, and so on. Windows users connecting to a UNIX server should be aware that the lowercased workstation names are used as the default names for new client workspaces. For example, if a new user creates a client workspace on a Windows machine named ROCKET, his client workspace is named rocket by default. If he later sets P4CLIENT to ROCKET (or Rocket, Perforce will tell him his workspace is undefined. He must set P4CLIENT to rocket (or unset it) to use the client workspace he defined.

If your Perforce server is running on Windows, your UNIX users must be aware that their Perforce server will store case-variant files in the same namespace.

For example, users who try something like this:

C:\> p4 add dir/file1
C:\> p4 add dir/file2
C:\> p4 add DIR/file3

should be aware that all three files will be stored in the same depot directory. The depot pathnames and filenames assigned to the Windows server will be those first referenced. (In this case, the depot pathname would be dir, and not DIR.)

The Perforce server can be run in Unicode mode to convert certain elements from their unicode representation on the server, to the particular character set used on clients and triggers that communicate with the server. The following elements are converted:

Normally, setting the server in Unicode mode should automatically configure the appropriate rendering for each client, independently of the platform where it runs. However, there are some cases in which you might also have to configure the client. The following subsections describe how you set up the server and the client if needed, and offer some troubleshooting tips.

In addition to affecting the client, Unicode settings also affect trigger scripts that communicate with the server. You should check your trigger’s use of the elements noted above (file names, Perforce identifiers, etc.) and make sure that these are consistent with the character set used by the server.

How you configure a Unicode-mode server and the workstations that access it, depends on whether you are starting a server for the first time or whether you are converting an existing non-unicode server to unicode mode. The following sections explain each use case.

$ p4d -xi -r server_root [other options]

When you set up a server to work in unicode mode, the client determines what character set to use by examining the current environment and, generally, you should have nothing more to do to get a correct translation. For example a UNIX client examines the LANG or LOCALE variables to determine the appropriate character set. However, there might be situations when you need to override the selection made by the client:

In each of these cases, you will need to explicitly set P4CHARSET to an appropriate value or take some other action. To get a list of the possible values for P4CHARSET, use the command:

$ p4 help P4CHARSET

C:\> p4 -Q winansi files //...

To prevent file corruption, it is essential that you configure your workstation correctly. The following section describes common problems and provides solutions.

Use the -L flag to p4d or the environment variable P4LOG to specify Perforce’s error output file. If no error output file is defined, errors are dumped to the p4d process' standard error. Although p4d tries to ensure that all error messages reach the user, if an error occurs and the user application disconnects before the error is received, p4d also logs these errors to its error output.

Perforce also supports trace flags used for debugging. See Setting server trace and tracking flags for details.

If your site requires that user access to files be tracked, use the -A flag to p4d or the environment variable P4AUDIT to activate auditing and specify the Perforce’s audit log file. When auditing is active, every time a user accesses a file, a record is stored in the audit log file. This option can consume considerable disk space on an active installation.

See Auditing user file access for details.

If a user connects to a new Perforce service, performance-related properties are reloaded for the Perforce service to which the user has most recently connected.

You can use the following properties to enable or disable P4V features. These properties are read once, upon P4V startup, from the first service to which the user connects. Features that are deactivated by setting these properties to Off are unavailable in P4V and do not display in P4V’s Preferences page:

For example, the administrator of a site that does not use Perforce’s built-in defect tracking can disable access to jobs from within P4V by running:

$ p4 property -a -n P4V.Features.Jobs -v Off

A new property is added/updated (-a), it is named (-n) P4V.Features.Jobs, and it is assigned the value (-v) of Off.

If one group of users within the organization has a need to use the jobs functionality of P4V, the feature can be selectively (and centrally) re-enabled for those users with:

$ p4 property -a -n P4V.Features.Jobs -v On -g jobusers

The jobs feature of P4V is re-enabled by setting its value to On, but only for users in the jobusers group.

In order for P4V to connect to a Swarm server, it must know where the server is installed. Because Swarm is a web application, a URL can specify its location.

The Swarm or P4V administrator uses the P4.Swarm.URL[.serverid] property to specify the location of a Swarm server.

When P4V attempts to connect to a server that has no serverid, it checks to see if the property P4.Swarm.URL is set, and it uses that URL to access Swarm. If the property is not set, P4V does not attempt to talk to Swarm.

When P4V attempts to connect to a server that has a serverid,

If there is a value both for p4.Swarm.URL and for p4.Swarm.URL.myserverid when P4V attempts to connect to a Swarm server, the serverid match takes precedence over the generic match.

The user issuing the p4 property command must have an account on the specified Swarm server.

You can use the p4 property command to list the current properties of the Swarm server; for example:

$ p4 -p "10.5.40.145:1666" property -l -A
   P4.Swarm.Timeout = 10 (any) #1
   P4.Swarm.URL.master-1666 = https://my_swarm_server1.com

You can use the P4.Combine.URL property to enable the rich comparison of Microsoft Word .docx files through P4Merge. You must deploy P4Combine as part of a Commons deployment to use this feature.

To enable the feature, set the P4.Combine.URL server property to the P4Combine Web Service URL. P4V will then display a rich compare of .docx files in the P4Merge window, using HTML5 to show differences for text, images, formats, styles, tables, headers, footers, and other objects.