Other Information

Six flags are available to every Perforce command. These flags are typed between the OS command p4 and the Perforce command (e.g., p4 -c clientname submit). The six flags are:


`-c clientname`	Use clientname as the client workspace for the command. Overrides the value of `P4CLIENT`.
`-d directory`	Use directory as the current directory for the command, overriding the value of `PWD`.
`-p server_addr`	Take server_addr as the listening address of the Perforce server program p4d, overriding the value of `P4PORT`.
`-u username`	Specifies username as the Perforce user for this command. Overrides the value of `P4USER`.
`-x filename`	Tells the client program p4 to read arguments, one per line, from the named file.
`-P password`	Allows access to the server when password matches the password that has been set for the Perforce user the command is running as. Overrides the value of `P4PASSWD`.

Note that some of these flags have different meanings when they appear to the right of the named command in a full Perforce instruction. For example, the command

uses the -c flag twice; this command tells Perforce to submit changelist 30 in client workspace joe.

File Types

Specifying Files on Command Lines

File names provided as arguments to Perforce commands can be referred in one of two ways: by using the names of the files in the client workspace, or by providing the names of the files in the depot. When providing client workspace file names, the user may give the name in either local or Perforce syntax.

Local Syntax

Local syntax is simply a file's name as specified by the local shell or OS. This name may be an absolute path, or may be specified relative to the current directory, although it can only contain relative components at the beginning of the file name (i.e. it doesn't allow sub/dir/./here/foo.c). For example, on UNIX, a user could refer to a file as /usr/edk/elm/README, or in a number of other ways.

Perforce Syntax

Perforce provides its own filename syntax which remains the same across operating systems. Filenames specified in this way begin with two slashes and the client or depot name, followed by the path name of the file relative to the client or depot root directory. The components of the path are separated by slashes.

Perforce syntax is sometimes called depot syntax or client syntax, depending on whether the file specifier refers to a file in the depot or on the client. But the syntax is the same in either case.

Providing Files as Arguments to Commands

Because the client view provides a one-to-one mapping between any file in the client workspace and any file in the depot, any file can be specified within any Perforce command in client syntax, depot syntax, or local syntax. A depot's file specifier can be used to refer to a file in the client, and vice-versa. Perforce will do the necessary mapping to determine which file is actually used.

Any filenames provided to Perforce commands can be specified in any valid local syntax, or in Perforce syntax by depot or client. If a client filename is provided, Perforce uses the client view to locate the corresponding file in the depot. If a depot filename is given, the client view is used to locate the corresponding file in the client workspace.

Revision Specifiers

Many Perforce commands can act on older file versions. These older revisions can be retrieved by tacking a revision specification onto the end of the file name. There are nine types of revision specifications:


Revision Specifier	Meaning	Examples
`file#n`	Revision number	`p4 sync lock.c#3` Refers to revision 3 of file `lock.c`
`file@n`	A change number	`p4 sync lock.c@126` Refers to the version of `lock.c` when changelist 126 was submitted, even if it was not part of the change. `p4 sync //depot/...@126` Refers to the state of the entire depot at changelist 126
`file@label`	A label name	`p4 sync lock.c@beta` The revision of `lock.c` in the label called `beta`
`file@clientname`	A client name. The revision of file last taken into client workspace clientname.	`p4 sync lock.c@lisag_ws` The revision of `lock.c` last taken into client workspace `lisag_ws`
`file#none`	The nonexistent revision.	`p4 sync lock.c#none` Says that there should be no version of l`ock.c` in the client workspace, even if one exists in the depot.
`file#head`	The head revision, or latest version, of the file.	`p4 sync lock.c#head` Except for explicitly noted exceptions, this is identical to referring to the file with no revision specifier.
`file#have`	The revision on the current client. This is synonymous to `@client` where client is the current client name.	`p4 sync lock.c#have` The revision of `lock.c` found in the current client.
`file@date`	The head revision of the file at 00:00:00 on the morning of that date. Dates are specified as `YYYY/MM/DD`.	`p4 sync lock.c@1998/05/18` The head revision of `lock.c` as of 00:00:00, May 18, 1998.
`file@"date time"`	The head revision of the file in the depot on the given date at the given time. The date is specified as above; the time is specified as `HH:MM:SS`.	`p4 sync lock.c@"1998/05/18 15:21:34"` The head revision of lock.c as of May 18, 1998, at 3:21:34 pm The date and the time must be separated by a single space, and the entire string should be quoted. The time is specified on the 24-hour clock.

In all cases, if a file doesn't exist at the given revision number, it will appear as if the file doesn't exist at all. Thus, using a label to refer to a file that isn't in the label is indistinguishable from referring to a file that doesn't exist at all.

Revision Ranges

A few Perforce client commands can limit their actions to a range of revision numbers, rather than just a single revision. A revision range is two revision specifications, separated by a comma. If only a single revision is given where a revision range is expected, the named revision specifies the end of the range, and the start of the range is assumed to be 1. If no revision number or range is given where a revision range is expected, the default is all revisions.


p4 changes	p4 file	p4 integrate
p4 jobs	p4 print	p4 sync
p4 verify

Perforce Forms

Certain Perforce commands, such as p4 client and p4 submit, present a form to the user to be filled in with values. This form is displayed in the editor defined in the environment variable P4EDITOR. When the user changes the form and exits the editor, the form is parsed by Perforce, checked for errors, and used to complete the command operation. If there are errors, Perforce gives an error message and you must try again.

The rules of form syntax are simple: keywords must be against the left margin and end with a colon, and values must either be on the same line as the keyword or indented on the lines beneath the keyword. Only the keywords already present on the form are recognized. Some keywords, such as the Client: field in the p4 client form, take a single value; other fields, such as Description: , take a block of text; and others, like View: , take a list of lines.

Certain fields, like Client: in p4 client, can't have their values changed; others, like Description: in p4 submit, must have their values changed. If you don't change a field that needs to be changed, or vice-versa, the worst that will happen is that you'll get an error. We've done our best to make these cases as self-evident as possible; when in doubt, use p4 help command.