p4 server

Synopsis

Create, modify, or delete a Perforce server specification.

Syntax

p4 [g-opts] server serverID
p4 [g-opts] server -g
p4 [g-opts] server -d serverID
p4 [g-opts] server -o [-l] serverID
p4 [g-opts] server -i [-c edge-server|commit-server]
p4 [g-opts] server -c edge-server|commit-server serverID

Description

A server specification describes the high-level configuration and intended usage of a Perforce server. For installations with only one Perforce server, the server specification is optional.

The p4 server command puts the server spec into a temporary file and invokes the editor configured by the P4EDITOR variable. Saving the file creates or saves changes to the server specification.

The ClientDataFilter:, RevisionDataFilter:, and ArchiveDataFilter: fields are intended for use in replicated environments where you wish to filter out unnecessary data. (For instance, a build farm replica has little need to replicate the state, including the have list, for every open client workspace on the master server.) For further information about filtering in replicated environments, see Helix Versioning Engine Administrator Guide: Multi-site Deployment.

Warning

It is best if ArchiveDataFilter: is kept static. You must reseed the server if you change this filter.

An operator type user may not execute this command.

Form Fields

Field Name Type Description

ServerID:

Read-only

A unique identifier for this server. This must match the contents of the server’s server.id file as defined by the p4 serverid command.

Type:

Writable

Server executable type. One of the following:

  • server
  • proxy
  • broker
  • identifier

Each type may offer one or more services. See next.

Services:

Writable

The server type server provides the following services:

  • standard - a standard Perforce server
  • replica - a read-only replica server
  • commit-server - central server in distributed installation
  • edge-server - node in distributed installation
  • forwarding-replica - a replica configured to forward commands that involve database writes to a master server
  • build-server - a replica that supports build automation and build farm integration
  • P4AUTH - a server that provides authentication
  • P4CHANGE - a server that provides change numbering
  • depot-master - commit-server with automated failover
  • depot-standby - standby replica of the depot-master
  • standby - read-only replica server that uses p4 journalcopy
  • forwarding-standby - forwarding replica server that uses p4 journalcopy

The proxy type server provides a p4p caching proxy.

The broker type server provides the following services:

  • broker - a p4broker process

Name:

Writable

The P4NAME associated with this server.

You can leave this blank or you can set it to the same value as the serverid.

Address:

Writable

The P4PORT used by this server.

ExternalAddress:

Writable

For an edge server, this optional field specifies the external address used for connections to a commit server. This field must be set for the edge server to enable parallel submits in a federated environment.

Description:

Writable

An optional description for this server.

User:

Writable

The service user name used by the server. For additional information about the use of this field, see the section "Service users" in the chapter "Perforce Replication" in Helix Versioning Engine Administrator Guide: Multi-site Deployment.

ClientDataFilter:

Writable

For a replica server, this optional field can contain one or more patterns describing how active client workspace metadata is to be filtered. Active client workspace data includes have lists, working records, and pending resolves.

To include client data, use the syntax:

//client-pattern/...

To exclude client data, use the syntax:

-//client-pattern/...

All patterns are specified in client syntax.

RevisionDataFilter:

Writable

For a replica server, this optional field can contain one or more patterns describing how submitted revision metadata is to be filtered. Submitted revision data includes revision records, integration records, label contents, and the files listed in submitted changelists.

To include depot data, use the syntax:

//depot/pattern/...

To exclude depot data, use the syntax:

-//depot/pattern/...

All patterns are specified in depot syntax.

ArchiveDataFilter:

Writable

For a replica server, this optional field can contain one or more patterns describing the policy for automatically scheduling the replication of file content. If this field is present, only those files described by the pattern are automatically transferred to the replica; other files are not transferred until they are referenced by a replica command that needs the file content.

Files specified in the ArchiveDataFilter: field are transferred to the replica regardless of whether any users of the replica have made requests for their content.

To automatically transfer files on submit, use the syntax:

//depot/pattern/...

To exclude files from automatic transfer, use the syntax:

-//depot/pattern/...

All patterns are specified in depot syntax.

Warning

It is best if this filter is kept static. You must reseed the server if you change this filter.

DistributedConfig:

Writable

For an edge or commit server, this optional field, which is displayed only when you use the -l or -c option, shows configuration settings for this server.

  • -l flag shows the current configuration.
  • -c flag shows current configuration values, recommended default values for fields that are not set, or unset for fields that are not set and do not have default values.

If this field is present when invoked with -c, the configuration commands in this field are run on the current server using the scope of the server specified in the serverID field.

Options

-c edge-server | commit-server

Set or change configuration values used to set up the distributed environment on an edge or commit server. The specified service dictates which configuration values can be set. Configuration fields are initially populated with the configured values if set, default values if unset, or unset for unset values with no default.

After exiting from the form, any configuration commands in this field will be run on the current server for the scope of the serverID. Because the commands apply only to the ServerID server, the server# prefix is not allowed.

For more information, see the section "Shortcuts to configuring the server" in Helix Versioning Engine Administrator Guide: Multi-site Deployment.

-d serverID

Delete the named server specification.

-g

Generate a new serverID as part of the form.

-i

Read a server specification from standard input.

You can combine this option with the -c option to generate and run configuration variables used to set up an edge or commit server. When used with -c, only the fields explicitly set in standard input from the DistributedConfig field will be configured.

-l

Use with -o flag to display the values of the configuration variables used to set up the current edge or commit server in a distributed environment. This option shows the configuration commands in the DistributedConfig field.

-o

Write the named server specification to standard output.

g-opts

See “Global Options”.

Usage Notes

Can File Arguments Use Revision Specifier? Can File Arguments Use Revision Range? Minimal Access Level Required

N/A

N/A

see discussion below

Only super can run p4 server in update mode (using -i, -g, and -d options). Non-operators can run p4 server in non-update mode (using -o or -o -g options). Operators cannot run p4 server at all.

Related Commands

To change a server’s ID after creation

p4 serverid

To list all known servers

p4 servers