Any file can be specified within any Perforce command in client syntax, depot syntax, or local syntax. Client workspace names and depot names share the same namespace; there is no way for the Perforce server to confuse a client name with a depot name.
Local syntax refers to filenames as specified by the local shell or operating system. Filenames referred to in local syntax may be specified by their absolute paths or relative to the current working directory. (Relative path components may only appear at the beginning of a file specifier.)
Perforce has its own method of file specification which remains unchanged across operating systems. If a file is specified relative to a client root, it is said to be in client syntax. If it is specified relative to the top of the depot, it is said to be in depot syntax. A file specified in either manner can be said to have been specified in Perforce syntax. Perforce file specifiers always begin with two slashes (//), followed by the client or depot name, followed by the full pathname of the file relative to the client or depot root directory.
Path components in client and depot syntax are always separated by slashes (/), regardless of the component separator used by the local operating system or shell.
An example of each syntax is provided below:
| Syntax | Example |
|---|---|
| Local syntax | /staff/user/usercws/file.c |
| Depot syntax | //depot/source/module/file.c |
| Client syntax | //usercws/file.c |
The Perforce system allows the use of three wildcards:
File specifiers may be modified by appending # or @ to them. These are used to refer to specific revisions of files as stored in the depot:
| Modifier | Meaning |
|---|---|
| file#n | Revision specifier: The nth revision of file. |
| file#none | The nonexistent revision: If a revision of file exists in the depot, it will be ignored. This is useful when you want to remove a file from the client workspace while leaving it intact in the depot, e.g. p4 sync foo#none. |
| file#head | The head revision (latest version) of file. Except where explicitly noted, this is equivalent to referring to the file without a revision specifier. |
| file#have | The revision on the current client: the revision of file last p4 synced into the client workspace |
| file@n | Change number: The revision of file immediately after changelist n was submitted. |
| file@labelname | Label name: The revision of file in the label labelname. |
| file@clientname | Client name: The revision of file last taken into client workspace clientname. |
| file@datespec | Date and time: The revision of file at the date and time specified. If no time is specified, the head revision at 00:00:00 on the morning of the date specified will be returned. Dates are specified yyyy/mm/dd:hh:mm:ss. |
Revision specifiers can be used to operate on many files at once: p4 sync //myclient/...#4 will copy the fourth revision of all non-open files into the client workspace.
Perforce filenames may not contain unprintable characters, wildcards, nor the revision-specifying characters @ and #.
If specifying files by date and time (i.e. using specifiers of the form file@datespec), the date specification should be parsed by your local shell as a single token. You may need to use quotation marks around the date specification if you use it to specify a time as well as a date.
Some of Perforce's file specification characters may be intercepted and interpreted by the local shell. These will have to be escaped before use. For instance, # is used as the comment character in most UNIX shells, / may be interpreted by (non-Perforce) DOS commands as an option specifier, and MacOS uses the : character as the separator between local path components. For information on these and other platform-specific issues, see the release notes for your platform.
A few Perforce commands can use revision ranges to modify file arguments. Revision ranges are two separate revision specifications, separated by a comma. For example, p4 changes foo#3,5 will list the changelists that submitted file foo at its third, fourth, and fifth revisions.
Revision ranges have two separate meanings, depending on which command you're using. The two meanings are:
Revision ranges can be very powerful. For example, p4 changes foo#3,@labelname will list all changelists that submitted file foo between its third revision and the revision stored in label labelname.