Helix Core P4 Command Reference (2019.1)

p4 server

Create, modify, or delete a Helix 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 Helix server. For installations with only one Helix 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.

An operator type user cannot execute this command. (The three user types are explained in the description of p4 user.)

Filtering

The ClientDataFilter:, RevisionDataFilter:, and ArchiveDataFilter: fields are for replicated environments where you filter out unnecessary data. For instance, a build farm replica do not need to replicate the have list for every open client workspace on the master server. See "Filtering meta during replication" in Helix Core Server Administrator Guide: Multi-Site Deployment.

Warning

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

Tip

(2019.1 and later) The server spec shows the configurables that apply to the server. See the DistributedConfig: field. The admin can modify these settings.

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. Important To avoid configuration problems, the value of `serverID` should always match the value of P4NAME if both are set. We recommend setting `serverID`, but support `P4NAME` for backward compatibility.
`Type:`	Writable	Server executable type. One of the following: `server` `proxy` `broker` connector Each type may offer one or more services.
`Services:`	Writable	The `server` type server provides the following services: standard - a standard Helix 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 standby - read-only replica server that uses p4 journalcopy forwarding-standby - forwarding replica server that uses p4 journalcopy local - personal DVCS server created by p4 init The `proxy` type server provides a `p4p` caching proxy. The `broker` type server provides a `p4broker` process. The connector type server provides the following services: git-connector - p4gconn caching proxy
Options:	Writable	mandatory: A standby or forwarding-standby server that persists journalcopy'ed metadata before that metadata is replicated to other replicas. A standby or forwarding-standby server with this option set can be used for failover whether or not the server from which it is journalcopy'ing is available at the time of the failover. nomandatory: (default) Replication to other replicas can occur before the metadata has been persisted by this standby or forwarding-standby server. Failover can occur to this standby or forwarding-standby server only if the server from which it is journalcopy'ing is available at the time of the failover.
ReplicatingFrom:	Writable	Server ID of the server from which this server is replicating or journalcopy'ing. This field is required when the server is a standby or forwarding-standby server and the mandatory option is set for either.
`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 can contain its external address for connections from the commit server. This field is required for distributed parallel submit. For a Git Connector server, this optional field contains a list of repos to be updated. See the Configuring Git Connector to Poll Repos from Helix4Git topic in the Helix4Git Administration Guide.
`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 Helix Core Server 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 all server types, the DistributedConfig field of that server spec shows a line for each configurable that is set to a non-default value. In this field, you can edit the value, add a new line to set a different configurable to a non-default value, or delete a line to reset that configurable to its default value. For all servers, this optional field shows configuration settings relevant to this server. When p4 server is invoked with the -c flag, the configuration values are populated with currently configured values, recommended default values if unset, or unset for unset values with no default. 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 ServerID server. For an edge or commit server, this optional field, which is displayed only when you use the -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`	Allow the user to set, change or display configuration values used to set up the distributed environment on an edge or commit server by using the DistributedConfig: field. 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 the DistributedConfig: field will be run on the current server for the scope of the serverID. The commands only apply to the serverID server, and so the server# prefix is not allowed in these commands. The only supported services are edge-server and commit-server. The service dictates which configuration values are used to initially populate the form the first time that the server command is run.
`-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`	deprecated because of the functionality of 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`

Your search for returned result(s).