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 can be specified by their absolute paths or relative to the current working directory. (Relative path components can 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.
The # and
@ specifiers refer to specific revisions of files as stored in the depot:
Revision specifiers can be used to operate on many files at once: p4 sync //myclient/...#4 copies the fourth revision of all non-open files into the client workspace.
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 Perforce file specification characters may be intercepted and interpreted by the local shell, and need to be escaped before use. For instance,
# is used as the comment character in most UNIX shells, and
/ may be interpreted by (non-Perforce) DOS commands as an option specifier. File names with spaces in them may have to be quoted on the command line.
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 file#3,5 lists the changelists that submitted file
file at its third, fourth, and fifth revisions.
Revision ranges can be very powerful. For example, the command p4 changes file#3,@labelname lists all changelists that submitted file
file between its third revision and the revision stored in label
labelname.
The pathname component separator (/) is not permitted in filenames, depot names, or client workspace names, but can appear in label names, job names, or user names. The recursive subdirectory wildcard (
...) is not permitted in file names, label names, or other identifiers.
To refer to files containing the Perforce revision specifier wildcards (@ and
#), file matching wildcard (
*), or positional substitution wildcard (
%%) in either the file name or any directory component, use the ASCII expression of the character's hexadecimal value. ASCII expansion applies only to the following four characters:
To add a file such as [email protected], force a literal interpretation of special characters by using:
Most special characters tend to be difficult to use in filenames in cross-platform environments: UNIX separates path components with
/, while many DOS commands interpret
/ as a command line switch. Most UNIX shells interpret
# as the beginning of a comment. Both DOS and UNIX shells automatically expand
* to match multiple files, and the DOS command line uses
% to refer to variables.
Similarly, although non-ASCII characters are allowed in filenames and Perforce identifiers, entering these characters from the command line may require platform-specific solutions. Users of GUI-based file managers can manipulate such files with drag-and-drop operations.
Copyright 1999-2009 Perforce Software.
