development/p4: Added (cli client for Perforce)

Signed-off-by: Robby Workman <rworkman@slackbuilds.org>

1 files changed, 2254 insertions, 0 deletions

diff --git a/development/p4/p4.man b/development/p4/p4.man
new file mode 100644
index 0000000000..842165a697
--- /dev/null
+++ b/development/p4/p4.man
@@ -0,0 +1,2254 @@
+.\" Copyright 2000 Perforce Software
+.\" $Id: //depot/r05.2/p4-doc/man/p4.1#1 $
+.TH P4 1 "7 July 2001"
+.SH NAME
+p4 \- Perforce source management system client
+.SH SYNOPSIS
+.B p4
+[
+.BI options
+]
+.BI command
+.BI arg ...
+.SH DESCRIPTION
+.B p4
+is the client program used to interact with the
+source management system repository server.
+
+.SH OPTIONS
+.TP
+.B -c \fIclient\fP
+The -c flag specifies the client name, overriding the value of
+$P4CLIENT in the environment and the default (the hostname).
+.TP
+.B -d \fIdirectory\fP
+The -d flag specifies the current directory, overriding the value of
+$PWD in the environment and the default (the current directory).
+.TP
+.B -H \fIhost\fP
+The -H flag specifies the host name, overriding the value of
+$P4HOST in the environment and the default (the hostname).
+.TP
+.B -p \fIport\fP
+The -p flag specifies the server's listen address, overriding the
+value of $P4PORT in the environment and the default (perforce:1666).
+.TP
+.B -P \fIpassword\fP
+The -P flag specifies the password, overriding the value of
+$P4PASSWD in the environment.
+.TP
+.B -s
+The -s flag causes the p4 client program to prefix each line of
+output with a tag (error, warning, info, text, exit) so as to make
+it amenable to scripting.
+.TP
+.B -u \fIuser\fP
+The -u flag specifies the user name, overriding the value of
+$P4USER, $USER, and $USERNAME in the environment.
+.TP
+.B -v \fIx\fP
+The -v flag sets the debug output level.
+.TP
+.B -x \fIfile\fP
+The -x flag instructs p4 to read arguments, one per line, from the
+named file.  If the file is named '-', then standard input is read.
+.TP
+.B -V
+The -V flag displays the version of the p4 client command and exits.
+
+.SH USAGE
+.B p4
+is the client interface for the
+.SM Perforce
+source management system.
+.B p4
+connects to the server daemon,
+.B p4d,
+which manages access to the central respository, or depot. 
+.B p4 
+uses environment variable
+.B $P4PORT
+to determine the connection address of the server daemon (using
+.B perforce:1666
+as default).  Each
+.B p4
+client workspace is identified by a name,
+determined by the environment variable
+.B $P4CLIENT
+(using hostname as default.)
+Information associated with each client workspace includes
+a root directory in the client machine file system and a view definition
+which provides a mapping between file names on the client and files in
+the depot.  This information is maintained in the depot database.
+.LP
+The following commands are recognized:
+.LP
+.nf
+    add        Open a new file to add it to the depot
+    admin      Perform administrative operations on the server
+    branch     Create or edit a branch specification
+    branches   Display list of branches
+    change     Create or edit a changelist description
+    changes    Display list of pending and submitted changelists
+    client     Create or edit a client specification and its view
+    clients    Display list of known clients
+    counter    Display, set, or delete a counter
+    counters   Display list of known counters
+    delete     Open an existing file to delete it from the depot
+    depot      Create or edit a depot specification
+    depots     Display list of depots
+    describe   Display a changelist description
+    diff       Display diff of client file with depot file
+    diff2      Display diff of two depot files
+    dirs       List subdirectories of a given depot directory
+    edit       Open an existing file for edit
+    filelog    List revision history of files
+    files      List files in the depot
+    fix        Mark jobs as being fixed by named changelists
+    fixes      List what changelists fix what job
+    flush      Fake a 'p4 sync' by not moving files
+    fstat      Dump file info
+    group      Change members of a user group
+    groups     List groups (of users)
+    have       List revisions last synced
+    help       Print this help message
+    info       Print out client/server information
+    integrate  Schedule integration from one file to another
+    integrated Show integrations that have been submitted
+    job        Create or edit a job (defect) specification
+    jobs       Display list of jobs
+    jobspec    Edit the job template
+    label      Create or edit a label specification and its view
+    labels     Display list of labels
+    labelsync  Synchronize label with the current client contents
+    lock       Lock an opened file against changelist submission
+    obliterate Remove files and their history from the depot
+    opened     Display list of files opened for pending changelist
+    passwd     Set the user's password on the server (and Windows client)
+    print      Retrieve a depot file to the standard output
+    protect    Modify protections in the server namespace
+    rename     Explains how to rename files
+    reopen     Change the type or changelist number of an opened file
+    resolve    Merge open files with other revisions or files
+    resolved   Show files that have been merged but not submitted
+    revert     Discard changes from an opened file
+    review     List and track changelists (for the review daemon)
+    reviews    Show what users are subscribed to review files
+    set        Set variables in the registry (Windows only)
+    submit     Submit open files to the depot
+    sync       Synchronize the client with its view of the depot
+    triggers   Modify list of pre-submit triggers
+    typemap    Modify the file name-to-type mapping table
+    unlock     Release a locked file but leave open
+    user       Create or edit a user specification
+    users      Display list of known users
+    verify     Verify that the server archives are intact
+    where      Show how file names map through the client view
+.fi
+
+.SH COMMANDS
+
+.TP
+.B p4 add [ -c changelist# ] [ -t filetype ] file ...
+.IP
+Open a new file for adding to the depot. If the file exists
+on the client it is read to determine if it is text or binary.
+If it does not exist it is assumed to be text. The file must
+either not exist in the depot, or it must be deleted at the
+current head revision. Files may be deleted and re-added.
+.IP
+If the -c flag is given the open files are associated with the
+specified pending changelist number; otherwise the open files are
+associated with the default changelist.
+.IP
+If file is already open it is moved into the specified pending
+changelist. It is not permissible to reopen a file for add unless
+it was already open for add.
+.IP
+If -t filetype is given the file is explicitly opened as that
+filetype. Otherwise, the filetype is determined by the file
+name-to-type mapping table managed by "p4 typemap". If the file
+name is not mapped in that table, "p4 add" senses the filetype
+by examining the file"s contents and execution permission bits.
+See "p4 help filetypes" for a complete list.
+.TP
+.B p4 admin checkpoint [ -z ] [ prefix ]
+.TP
+.B p4 admin stop
+.IP
+"p4 admin checkpoint" causes the server to take a checkpoint and
+to copy the journal to a numbered journal file. It is equivalent
+to "p4d -jc".
+.IP
+The -z flag causes the checkpoint and saved journal to be saved in
+compressed (gzip) format, with the ".gz" suffix on the file names.
+.IP
+If a prefix is specified, the files will be named prefix.ckp.n and
+prefix.jnl.n respectively, where n is a sequence number. Without
+prefix, the default filenames checkpoint.n and journal.n will be
+used.
+.IP
+"p4 admin stop" stops the server, terminating any requests
+currently running. It first locks the database to ensure that
+no updates are taking place, but otherwise is brutal as it does
+not wait for users to finish what they are doing.
+(For NT users, this will work whether you are running Perforce
+as a server or a service.)
+.TP
+.B p4 branch [ -f ] name
+.TP
+.B p4 branch -d [ -f ] name
+.TP
+.B p4 branch -o name
+.TP
+.B p4 branch -i [ -f ]
+.IP
+Create a new branch specification or edit an existing branch
+specification. The specification form is put into a temporary
+file and the editor (given by the environment variable $P4EDITOR)
+is invoked.
+.IP
+The branch specification form contains the following fields:
+.RS
+.TP
+Branch:
+The branch name (read only.)
+.RE
+.RS
+.TP
+Owner:
+The user who created this branch. Can be changed.
+.RE
+.RS
+.TP
+Update:
+The date specification was last modified.
+.RE
+.RS
+.TP
+Access:
+The date of the last "integrate" using this branch.
+.RE
+.RS
+.TP
+Description:
+A short description of the branch (optional).
+.RE
+.RS
+.TP
+Options:
+Flags to change the branch behavior.
+.RE
+.RS
+.RS
+.TP
+locked
+Allows only the branch owner to change its
+specification. Prevents the branch from
+being deleted.
+.RE
+.RE
+.RS
+.TP
+View:
+A mapping from the source files of the branch to the
+target files of the branch. Both the left and right
+hand sides of the mappings refer to the depot namespace.
+See "p4 help views" for more on views.
+.RE
+.IP
+New branches are created with a default view that maps all depot
+files back into themselves. This view must be changed before the
+branch view is usable.
+.IP
+A branch definition is used only by the "p4 integrate" command.
+.IP
+The -d flag deletes the named branch.
+.IP
+The -o flag causes the named branch specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a branch specification to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+The -f flag allows the superuser to delete any branch; normally
+branches can only be deleted by their owner. -f also allows the
+last modified date to be set.
+.TP
+.B p4 branches
+.IP
+Reports the list of all branches currently known to the system.
+Branches takes no arguments.
+.TP
+.B p4 change [ -f -s ] [ changelist# ]
+.TP
+.B p4 change -d [ -f -s ] changelist#
+.TP
+.B p4 change -o [ -s ] [ changelist# ]
+.TP
+.B p4 change -i [ -f -s ]
+.IP
+"p4 change" creates and edits changelists and their descriptions.
+With no argument, "p4 change" creates a new changelist. If a
+changelist number is given, "p4 change" edits an existing, pending
+changelist. In both cases the changelist specification is placed
+into a form and the user"s editor is invoked.
+.IP
+The -d flag discards a pending changelist, but only if it has no
+opened files and no pending fixes associated with it. Use "p4
+opened -a" to report on opened files and "p4 reopen" to move them
+to another changelist. Use "p4 fixes -c changelist#" to report on
+pending fixes and "p4 fix -d -c changelist# jobs..." to delete
+pending fixes. The changelist can only be deleted by the user and
+client who created it, or by a superuser using the -f flag.
+.IP
+The -o flag causes the changelist specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a changelist specification to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+The -f flag allows the superuser to update or delete other users"
+pending changelists. -f also allows the superuser to delete
+submitted changelists once they have been emptied of files via
+"p4 obliterate". Normally, submitted changelists are immutable.
+.IP
+The -s flag extends the list of jobs to include the fix status
+for each job. On new changelists, the fix status begins as the
+special status "ignore", which if left unchanged simply excludes
+the job from those being fixed. Otherwise, the fix status, like
+that applied with "p4 fix -s", becomes the job"s status when
+the changelist is committed. Note that this option is not meant
+for end-users. It exists to support propagating information from
+an external defect tracking system.
+.TP
+.B p4 changes [ -i -l -m max -s status ] [ file[revRange] ... ]
+.IP
+Reports the list of all pending and submitted changelists currently
+known to the system.
+.IP
+If files are specified, "p4 changes" limits its report to
+changelists that affect those files. If the file specification
+includes a revision range, "p4 changes" limits its report to
+submitted changelists that affect those particular revisions.
+See "p4 help revisions" for help specify revisions.
+.IP
+The -i flag also includes any changelists integrated into the
+specified files.
+.IP
+The -l flag produces long output with the full text of the changelist
+descriptions.
+.IP
+The -m max flag limits changes to the "max" most recent.
+.IP
+The -s status flag limits the output to pending or submitted
+changelists.
+.TP
+.B p4 client [ -f -t template ] [ name ]
+.TP
+.B p4 client -d [ -f ] name
+.TP
+.B p4 client -o [ -t template ] [ name ]
+.TP
+.B p4 client -i [ -f ]
+.IP
+With no argument "p4 client" creates a new client view specification or
+edits an existing client specification. The client name is taken
+from the environment variable $P4CLIENT if set, or else from
+the current host name. The specification form is put into a
+temporary file and the editor (given by the environment variable
+$P4EDITOR) is invoked. If a name is given, the specification of
+the named client is displayed read-only.
+.IP
+The specification form contains the following fields:
+.RS
+.TP
+Client:
+The client name (read only.)
+.RE
+.RS
+.TP
+Host:
+If set, restricts access to the named host.
+If unset, access is allowed from any host.
+.RE
+.RS
+.TP
+Owner:
+The user who created this client. Can be changed.
+.RE
+.RS
+.TP
+Update:
+The date this specification was last modified.
+.RE
+.RS
+.TP
+Access:
+The date this client was last used in any way.
+.RE
+.RS
+.TP
+Description:
+A short description of the client (optional).
+.RE
+.RS
+.TP
+Root:
+The root directory of the client file workspace
+(given in local file system syntax), under which all
+client files will be placed. If you change this, you
+must physically relocate any files as well.
+The special name "null" may be used to allow files
+to be mapped to multiple drives on Windows clients.
+.RE
+.RS
+.TP
+Options:
+Flags to change the client behavior. The defaults
+are marked with *.
+.RE
+.RS
+.RS
+.TP
+allwrite
+.TP
+noallwrite * 
+Leaves all files writable on the client;
+else only checked out files are writable.
+.RE
+.RE
+.RS
+.RS
+.TP
+clobber
+.TP
+noclobber * 
+Allows "p4 sync" to overwrite writable
+files on the client.
+.RE
+.RE
+.RS
+.RS
+.TP
+compress
+.TP
+nocompress * 
+Compresses data sent between the client
+and server to speed up slow connections.
+.RE
+.RE
+.RS
+.RS
+.TP
+locked
+.TP
+unlocked * 
+Allows only the client owner to use the
+client or change its specification.
+Prevents the client from being deleted.
+.RE
+.RE
+.RS
+.RS
+.TP
+modtime
+.TP
+nomodtime * 
+Causes "p4 sync" to preserve file
+modification time from submitting client,
+as with files with +m type modifier.
+Otherwise modification time is left as
+when the file was fetched.
+.RE
+.RE
+.RS
+.RS
+.TP
+rmdir
+.TP
+normdir *
+Makes "p4 sync" attempt to delete a client
+directory when all files are removed.
+.RE
+.RE
+.IP
+LineEnd: Set line ending character(s) for client text files.
+.RS
+.RS
+.TP
+local
+Use mode native to the client (default).
+.RE
+.RE
+.RS
+.RS
+.TP
+unix
+linefeed: UNIX style.
+.RE
+.RE
+.RS
+.RS
+.TP
+mac
+carriage return: Macintosh style.
+.RE
+.RE
+.RS
+.RS
+.TP
+win
+carriage return-linefeed: Windows style.
+.RE
+.RE
+.RS
+.RS
+.TP
+share
+hybrid: writes UNIX style but reads UNIX or
+Windows style.
+.RE
+.RE
+.RS
+.TP
+View:
+A mapping from the files in the depot to files in the
+client workspace. This is the mechanism by which you
+select what files you want on your client and where you
+want them to be. The default view maps all depot files
+onto the client. See "p4 help views" for view syntax.
+A new view takes effect on the next "p4 sync".
+.RE
+.RS
+.TP
+Note:
+changing the client root does not actually move the client
+files; you must relocate them yourself. Similarly, changing
+the "LineEnd" option does not actually update the client files;
+you can refresh them with "p4 sync -f".
+.RE
+.IP
+The -d flag causes the named client to be deleted, as long as it
+has no opened files. The -f forces the delete
+.IP
+The -o flag causes the named client specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a client specification to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+The -t flag constructs the client"s view by copying the named
+template client"s view, instead of using the existing view or
+creating a new default view.
+.IP
+The -f flag allows the superuser to modify locked clients; normally
+locked clients can only be modified by their owner. -f also allows
+the last modified date to be set.
+.TP
+.B p4 clients
+.IP
+Reports the list of all clients currently known to the system.
+.TP
+.B p4 counter name
+.TP
+.B p4 counter [ -f ] name value
+.TP
+.B p4 counter -d name
+.IP
+The first form displays the value of the named counter.
+.IP
+The second form sets the counter to the given value. The -f flag
+sets even those used by Perforce, as listed in "p4 help counters".
+Moving the "change" counter backwards can have very bad results.
+.IP
+The third form deletes the counter. This usually has the same
+effect as setting the counter to 0.
+.IP
+"p4 counter" requires "review" access granted by "p4 protect".
+The -f flag require "super" access.
+.TP
+.B p4 counters
+.IP
+Reports the list of all counters in use by the server. There are
+four counters the server uses directly:
+.RS
+.RS
+.TP
+change
+the current change number
+.RE
+.RE
+.RS
+.RS
+.TP
+job
+the current job number
+.RE
+.RE
+.RS
+.RS
+.TP
+journal
+the current journal number
+.RE
+.RE
+.RS
+.RS
+.TP
+upgrade
+the server database upgrade level
+.RE
+.RE
+.IP
+Other counters can be created by the "p4 counter" or "p4 review"
+commands.
+.TP
+.B p4 delete [ -c changelist# ] file ...
+.IP
+Opens a file that currently exists in the depot for deletion.
+If the file is present on the client it is removed. If a pending
+changelist number is given with the -c flag the opened file is
+associated with that changelist, otherwise it is associated with
+the "default" pending changelist.
+.IP
+Files that are deleted generally do not appear on the have list.
+.TP
+.B p4 depot name
+.TP
+.B p4 depot -d name
+.TP
+.B p4 depot -o name
+.TP
+.B p4 depot -i
+.IP
+Create a new depot specification or edit an existing depot
+specification. The specification form is put into a temporary
+file and the editor (given by the environment variable $P4EDITOR)
+is invoked.
+.IP
+The depot specification form contains the following fields:
+.RS
+.TP
+Depot:
+The name of the depot. This cannot conflict with
+any branch, client, or label name.
+.RE
+.RS
+.TP
+Owner:
+The user who created this depot.
+.RE
+.RS
+.TP
+Date:
+The date this specification was last modified.
+.RE
+.RS
+.TP
+Description:
+A short description of the depot (optional).
+.RE
+.RS
+.TP
+Type:
+"local" or "remote". Normally depots are locally
+managed by the server and occupy space in the server"s
+root directory. A "remote" depot is a reference to
+files in another Perforce server.
+.RE
+.RS
+.TP
+Address:
+For remote depots, the $P4PORT (connection address)
+of the remote server.
+.RE
+.RS
+.TP
+Map:
+Path translation information, in the form of a file
+pattern with a single ... in it. For local depots,
+this path is relative to the server"s root directory
+(e.g. depot/...). For remote depots, this path refers
+to the remote server"s namespace (e.g. //depot/...).
+.RE
+.IP
+The -d flag deletes the named depot. If any files exist in the
+depot they must be removed first with "p4 obliterate".
+.IP
+The -o flag causes the named depot specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a depot specification to be read from the
+standard input. The user"s editor is not invoked.
+.TP
+.B p4 depots
+.IP
+Reports the list of all depots created via the depot command.
+Depots takes no arguments.
+.TP
+.B p4 describe [ -d<flag> -s ] changelist#
+.IP
+Display a changelist description, including the changelist number,
+user, client, date of submission, textual description, list
+of affected files and diffs of files updated. Pending changelists
+are flagged as "pending" and the list of affected files and
+file diffs is not displayed.
+.IP
+The -d<flag> passes a flag to the built-in diff routine to modify
+the output: -dn (RCS), -dc (context), -ds (summary), -du (unified).
+.IP
+The -s flag requests a shortened form of describe that doesn"t
+include the diffs of files updated.
+.TP
+.B p4 diff [ -d<flag> -f -sa -sd -se -sr -t ] [ file[rev] ... ]
+.IP
+Run diff (on the client) of a client file against the corresponding
+revision in the depot. The file is only compared if the file is
+opened for edit or the revision provided with the file argument is
+not the same as the revision had by the client. See "p4 help
+revisions" for help specifying revisions.
+.IP
+If no file argument is given, diff all open files.
+This can be used to view pending changelists.
+.IP
+The -d<flag> passes a flag to the built-in diff routine to modify
+the output: -dn (RCS), -dc (context), -ds (summary), -du (unified).
+.IP
+The -f flag forces a diff for every file, regardless of whether
+they are opened or if the client has the named revision.
+This can be used to verify the client contents.
+.IP
+The -s flag reduces the output of diff to the names of files
+satisfying the following criteria:
+.RS
+.RS
+.TP
+-sa
+Opened files that are different than the revision
+in the depot, or missing.
+.RE
+.RE
+.RS
+.RS
+.TP
+-sd
+Unopened files that are missing on the client.
+.RE
+.RE
+.RS
+.RS
+.TP
+-se
+Unopened files that are different than the revision
+in the depot.
+.RE
+.RE
+.RS
+.RS
+.TP
+-sr
+Opened files that are the same as the revision in the
+depot.
+.RE
+.RE
+.IP
+The -t flag forces "p4 diff" to diff even files with non-text
+(binary) types.
+.IP
+If the environment variable $P4DIFF is set then the named program is
+used rather than the implementation of diff included in the client.
+The -d<flag>command can be used to pass arguments to the
+external program. The -s flag is only implemented internally.
+.TP
+.B p4 diff2 [ -d<flag> -q -t ] file1 file2
+.TP
+.B p4 diff2 [ -d<flag> -q -t ] -b branch [ [ file1 ] file2 ]
+.IP
+Run diff (on the server) of two files in the depot. Both files
+may optionally include a revision specification; the default is
+to compare the head revision. See "p4 help revisions" for help
+specifying revisions. Wildcards may be used, but they must
+match between file1 and file2.
+.IP
+Diff2 introduces each diff with a header line of the form
+.IP
+==== file1 (type1) - file2 (type2) ==== summary
+.IP
+file1 or file2 may be "<none>", meaning that only one of the
+matched files actually exists at the given revision. The
+summary is one of: "identical" - file contents are identical and
+types are the same, "types" - file contents are identical but
+the types are different, and "content" - file contents are
+different.
+.IP
+The -b flag causes diff2 to use the branch view to specify the
+pairs of files to compare. If file arguments are also present, they
+can further limit the files and specify the revisions for comparison.
+Note that if only one file is given, it restricts the right-hand
+side of the branch view.
+.IP
+The -d<flag> passes a flag to the built-in diff routine to modify
+the output: -dn (RCS), -dc (context), -ds (summary), -du (unified).
+.IP
+The -q suppresses the display of the header lines of files whose
+content and types are identical and suppresses the actual diff
+for all files.
+.IP
+The -t flag forces "p4 diff2" to diff even files with non-text
+(binary) types.
+.TP
+.B p4 dirs [ -C -D -H ] dir[revRange] ...
+.IP
+List any directories matching the file pattern dir. Because of
+implementation details, "p4 dirs" does not allow the ... wildcard.
+Use the * wildcard instead.
+.IP
+Perforce does not track directories per se, but instead considers
+a path a directory if there are any undeleted files with that path
+as a prefix.
+.IP
+If the dir argument includes a revision range, then only directories
+with files of those revisions are listed. Normally directories with
+any files are listed. See "p4 help revisions" for help specifying
+revisions.
+.IP
+The -C flag limits the output to directories that are mapped on
+the current client.
+.IP
+The -D includes directories with only deleted files.
+.IP
+The -H flag lists directories of files on the "have" list.
+.TP
+.B p4 edit [ -c changelist# ] [ -t filetype ] file ...
+.IP
+Open an existing file for edit. The server notes that the current
+user on the current client has the file opened, and then changes
+the file permission from read-only to read/write.
+.IP
+If -c changelist# is given, the file is put into the pending
+changelist; the changelist must have been previously created by
+"p4 change". Otherwise the file is opened in the "default"
+(unnumbered) changelist.
+.IP
+If -t filetype is given the file is explicitly opened as that
+filetype. Otherwise, the type of the previous revision is reused.
+See "p4 help filetypes" for a complete list.
+.TP
+.B p4 filelog [ -i -l -m maxRevs ] file ...
+.IP
+List the revision history of the files named, working backwards
+from the latest revision to the first.
+.IP
+The -i flag follows branches. If a file was created by branching,
+"p4 filelog" also lists the revisions of the source file, but
+only those revisions leading up to the branch point.
+.IP
+The -l flag produces long output with the full text of the
+changelist descriptions.
+.IP
+The -m maxRevs displays at most "maxRevs" revisions per file.
+.TP
+.B p4 files file[revRange] ...
+.IP
+List files named or matching wild card specification. Display
+shows depot file name, revision, file type, change action and
+changelist number of the current head revision. If client file
+names are given as arguments the view mapping is used to list the
+corresponding depot files.
+.IP
+If the file argument has a revision, then all files as of that
+revision are listed. If the file argument has a revision range,
+then only files selected by that revision range are listed, and
+the highest revision in the range is used for each file. Normally,
+the head revision is listed. See "p4 help revisions" for help
+specifying revisions.
+.TP
+.B p4 fix [ -d ] [ -s status ] -c changelist# jobName ...
+.IP
+"p4 fix" marks each named job as being fixed by the changelist
+number given with -c. The changelist may be either pending or,
+submitted and the jobs may be still be opened or already closed
+(fixed by another changelist).
+.IP
+If the changelist has already been submitted and the job is still
+open then "p4 fix" marks the job closed. If the changelist has not
+been submitted and the job is still open, the job will be marked
+closed when the changelist is submitted. If the job is already
+closed, it is left alone.
+.IP
+The -d flag causes the specified fixes to be deleted. This does not
+otherwise affect the named changelist or jobs.
+.IP
+The -s uses the given status instead of the default "closed". This
+status is reported by "p4 fixes" and also reflected in the job"s
+status (immediately if the changelist is committed; on submission
+if the changelist is pending).
+.TP
+.B p4 fixes [ -i ] [ -j jobName ] [ -c changelist# ] [ file[revRange] ... ]
+.IP
+"p4 fixes" shows all jobs with fix records associated with them,
+along with the changelist number of the fix. Fix records are
+created either directly with the "p4 fix" command or via changelist
+creation with the "p4 change" and "p4 submit" commands.
+.IP
+The "p4 fixes" command show fixes regardless of whether the
+changelists are submitted or still pending.
+.IP
+By default, "p4 fixes" lists all fixes. This list can be limited
+in any of three ways. If -j jobName is given, only fixes for the
+named job are listed. If -c changelist# is given, only fixes from
+the numbered changelist are listed. If a file (pattern) is given,
+only fixes for submitted changelists affecting that file (or set of
+files) are listed. The file pattern may include wildcards and/or a
+revision number range. See "p4 help revisions" for help specifying
+revisions.
+.IP
+The -i flag also includes any fixes made by changelists integrated
+into the specified files.
+.TP
+.B p4 flush [ -f -n ] [ file[revRange] ... ]
+.IP
+"p4 flush" is a variant of "p4 sync" that bypasses the client file
+update. It can be used to make the server believe that a client
+workspace already has a file.
+.IP
+Because "p4 flush" doesn"t move files, it works especially quickly.
+As its purpose is to correct the Perforce server when it is wrong
+about what files are on the client, use of "p4 flush" can confuse
+the server if you are wrong about the client"s contents.
+.IP
+"p4 flush" takes the same flags as "p4 sync".
+.TP
+.B p4 fstat [ -c changelist# ] [ -C -l -H -P -s -W ] file[rev] ...
+.IP
+Fstat is intended for programmatic interfaces into Perforce. It
+dumps information about each file, with each item of information on
+a separate line. Fstat is best used within a Perforce API application
+where the items can be accessed as variables, but its output is also
+suitable for parsing from the client command output.
+.IP
+The fields that fstat displays are:
+.RS
+.RS
+.TP
+clientFile
+-- local path
+.RE
+.RE
+.RS
+.RS
+.TP
+depotFile
+-- name in depot
+.RE
+.RE
+.RS
+.RS
+.TP
+headAction
+-- action at head rev, if in depot
+.RE
+.RE
+.RS
+.RS
+.TP
+headChange
+-- head rev changelist#, if in depot
+.RE
+.RE
+.RS
+.RS
+.TP
+headRev
+-- head rev #, if in depot
+.RE
+.RE
+.RS
+.RS
+.TP
+headType
+-- head rev type, if in depot
+.RE
+.RE
+.RS
+.RS
+.TP
+headTime
+-- head rev mod time, if in depot
+.RE
+.RE
+.RS
+.RS
+.TP
+haveRev
+-- rev had on client, if on client
+.RE
+.RE
+.RS
+.RS
+.TP
+action
+-- open action, if opened
+.RE
+.RE
+.RS
+.RS
+.TP
+change
+-- open changelist#, if opened
+.RE
+.RE
+.RS
+.RS
+.TP
+unresolved
+-- unresolved integration records
+.RE
+.RE
+.RS
+.RS
+.TP
+otherOpen
+-- set if someone else has it open
+.RE
+.RE
+.RS
+.RS
+.TP
+otherLock
+-- set if someone else has it locked
+.RE
+.RE
+.RS
+.RS
+.TP
+ourLock
+-- set if this user/client has it locked
+.RE
+.RE
+.IP
+The -c changelist# flag instructs fstat to display only files
+affected since the given changelist number. This operation is
+much faster than using a revision range on the affected files.
+.IP
+The -C, -H, and -W flags limits the output to files that are
+mapped, synced, and opened (respectively) on the current client.
+.IP
+The -P flag outputs the clientFile in Perforce syntax (//client/).
+Normally, clientFile is in local host syntax.
+.IP
+The -l includes a fileSize field (which may be expensive to compute).
+.IP
+The -s flag shortens the output by excluding client related data
+about the file.
+.TP
+.B p4 group name
+.TP
+.B p4 group -d name
+.TP
+.B p4 group -o name
+.TP
+.B p4 group -i
+.IP
+Create a new user group or add/delete members from an existing
+group. A group"s members can be users and/or other groups.
+The group specification form is put into a temporary file and
+the editor (given by the environment variable $P4EDITOR) is invoked.
+.IP
+A group exists when it has any users or other groups in it, and
+ceases to exist if all users and groups in it are removed.
+.IP
+Each group has a MaxResults field, which limits the data size for
+operations that the users in that group can perform. If MaxResults
+is "unlimited", no limit is imposed. A user"s MaxResults is the
+highest of any group with a limit to which he belongs. If the
+user belongs to no group with a limit, then his MaxResults is
+unlimited. See "p4 help maxresults" for more information.
+.IP
+The -d flag deletes all users and groups from the named group, thus
+deleting the whole group.
+.IP
+The -o flag causes the named group specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a group specification to be read from the
+standard input. The user"s editor is not invoked. The new
+group specification entirely replaces the previous.
+.IP
+All commands that require access granted by "p4 protect" consider
+a user"s groups when calculating access levels. Groups are also
+used to calculate a user"s MaxResults.
+.IP
+"p4 group" requires superuser access granted by "p4 protect".
+.TP
+.B p4 groups [ user ]
+.IP
+Displays the list of all groups of users created by the
+"p4 group" command. If a user argument is given, only groups
+with that user are displayed.
+.TP
+.B p4 have [ file ... ]
+.IP
+depot-file#revision - client-file
+.TP
+.B p4 help [ command ... ]
+.IP
+Print a help message about command. If no command name is given
+print a general help message about Perforce and give a list
+of available client commands.
+.TP
+.B p4 info
+.IP
+Info dumps out what the server knows about the client (the user
+name, the client name, and the client directory) and some server
+information (the server"s address, date, version, and license data).
+.TP
+.B p4 integrate [ options ] fromFile[revRange] toFile
+.TP
+.B p4 integrate [ options ] -b branch [ toFile[revRange] ... ]
+.TP
+.B p4 integrate [ options ] -b branch -s fromFile[revRange] [ toFile ... ]
+.RS
+.TP
+options:
+-c changelist# -d -f -i -n -r -t -v
+.RE
+.IP
+Integrate attempts to propagate changes between two sets of files:
+from the source files of the branch view to the target files of the
+branch view. The result is target files that are opened for the
+action reflecting changes made in the corresponding source files.
+The actions are either "branch" (for new files), "delete" (when the
+source file was deleted), or "integrate" (when the source file was
+changed). In all cases, the opened files must be submitted with
+"p4 submit" before the integration is reflected in the depot.
+.IP
+Files opened for "branch" or "integrate" are left read-only on the
+client. For "integrate", a subsequent "p4 resolve" command handles
+the actual merging. If merging takes more than one editing session,
+"p4 resolve -f" can be used to revisit a merge. In this normal case
+a later "p4 integrate -r" knows that the results of the merge don"t
+need to be merged back.
+.IP
+You can downgrade a file opened for "integrate" or "branch" to
+"edit" or "add" and gain write permission by reopening the file
+with the "p4 edit" command. Downgrading causes any later
+"p4 integrate -r" to want to merge the changes back into the
+source file.
+.IP
+A branch view may be given directly on the command line by stating
+the source (from) and target (to) files, or indirectly by naming
+a stored branch view with -b branch. A stored branch view may have
+many mappings, while a view on the command line can only have one.
+If a stored branch view is given, the target files and source
+files and revisions may be further limited on the command.
+.IP
+If no file specification is given then the entire branch view is
+examined for needed integrations. If a file specification is
+given, the integration is limited to only those target files.
+In both cases, the integration is also limited to those target
+files that are also in the client view.
+.IP
+If no revision specification is given then all revisions of the
+source file are considered for integration. If a single revision
+is given, then only revisions up to the given revision are included.
+If a pair of revisions is given (separated by a comma (,)) then
+only those revisions, inclusively, are integrated. Note that the
+revision specification concerns the fromFile, but is attached to
+the toFile. See "p4 help revisions" for help specifying revisions.
+.IP
+The -f flag forces integrate to act without regard for previous
+integration history. Normally, integrate skips any file revisions
+already integrated. Note: unless revRange is given as well, the -f
+flag will force "p4 resolve" perform merges without a common base.
+To avoid this, use -f only to force integration of specific changes.
+-f implies -i (below).
+.IP
+If -c changelist# is given, the files are opened in the numbered
+pending changelist instead of the "default" changelist.
+.IP
+The -d flag enables integrations around deleted revisions. If the
+target file has been deleted and the source file has changed, -d
+will re-branch the source file on top of the target file. If the
+source file has been deleted and the target file has changed, -d
+will delete the target file. Without -d, it refuses to mix
+outstanding edits with a deleted file.
+.IP
+The -i flag enables baseless merges. When integrating into an
+existing target file, "p4 integrate" selects which revision "p4
+resolve" uses as the base for its merge. That revision should be
+the revision of the source file just before the first revision being
+integrated. But if the first revision being integrated is the
+revision at which the source file was added, which can happen if
+there were no prior integrations between the source and target
+files, then "p4 integrate" refuses the baseless merge. The -i flag
+forces "p4 integrate" to schedule the merge, and "p4 resolve" then
+uses the first, added revision as the base.
+.IP
+The -n flag displays what integrations would be necessary but does
+not schedule them.
+.IP
+The -r flag reverses the mappings in the branch view, with the
+target files and source files exchanging place. The -b branch flag
+is required.
+.IP
+The -s fromFile[revRange] flag specifies the source (from) file.
+It is used with the -b branch flag to limit the integrate to just
+those selected source files. The integration is still limited to
+any stated target (to) files on the command line. The -s flag also
+causes the branch view to work bidirectionally, using the union of
+the mappings and the reversed mappings. When the -s flag is used
+the source revision range is attached to the source file, rather than
+to the target files. Yes, this is confusing to code, too.
+.IP
+The -t flag makes the source file"s filetype propagate to the target
+file. Normally, the target file retain its previous filetype.
+Newly branched files always use the source file"s filetype. The
+filetype can still be changed before "p4 submit" with "p4 reopen".
+.IP
+The -v flag makes "p4 integrate" work faster by not copying newly
+branched files to the client. In this case, the files can be
+fetched with "p4 sync" after they are submitted with "submit".
+[Note that this was the default behavior for newly branched files
+in release 97.2 and earlier.]
+.RS
+.TP
+Note:
+the syntax "p4 integrate -b branch toFile[revRange]" is
+provided for backwards compatibility, but is confusing because
+it mixes the target file with the source revisions.
+.RE
+.TP
+.B p4 integrated file ...
+.IP
+Integrated shows integrations that have already been submitted.
+Use "p4 resolve -n" to see unresolved integrations and "p4 resolved"
+to see resolved but unsubmitted integrations.
+.TP
+.B p4 job [ -f ] [ jobName ]
+.TP
+.B p4 job -d jobName
+.TP
+.B p4 job -o [ jobName ]
+.TP
+.B p4 job -i [ -f ]
+.IP
+"p4 job" creates and edits job specifications using an ASCII form.
+A job is a defect, enhancement, or other unit of intended work.
+The "p4 fix" command can associate changelists with jobs.
+.IP
+With no arguments, "p4 job" creates a blank job specification form
+and invokes the user"s editor. When the form is saved, a job name
+of the form jobNNNNNN is created. If a jobName is given on the
+command line either that named job will be created or, if the job
+already exists, the job can be modified.
+.IP
+As jobs are entered or updated, all fields are indexed for
+searching by "p4 jobs". Text fields are broken into individual
+alphanumeric words (punctuation and whitespace are ignored) and
+each word is entered, case folded, into the word index. Date
+fields are converted to an internal representation (seconds
+since 1970/01/01 00:00:00) and entered into the date index.
+.IP
+The fields of a job are defined by the "p4 jobspec" command.
+There is a simple default jobspec that is used if no explicit
+one has been defined.
+.IP
+The -d flag deletes the named job and any associated fixes.
+.IP
+The -o flag causes the named job specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a job specification to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+The -f flag allows otherwise read-only fields to be set.
+.TP
+.B p4 jobs [ -e jobview -i -l -m max -r ] [ file[revRange] ... ]
+.TP
+.B p4 jobs -R
+.IP
+Reports the list of all jobs currently known to the system. If
+a file (pattern) is given, only fixes for submitted changelists
+affecting that file (or set of files) are listed. The file pattern
+may include wildcards and/or a revision number range. See "p4 help
+revisions" for help specifying revisions.
+.IP
+The -e jobview limits the output to jobs satisfying the expression
+given as "jobview". See "p4 help jobview" for a description of
+jobview syntax.
+.IP
+The -i flag also includes any fixes made by changelists integrated
+into the specified files.
+.IP
+The -l flag produces long output with the full text of the job
+descriptions.
+.IP
+The -m max flag limits the output to the first "max" jobs,
+ordered by their job name.
+.IP
+The -r flag sorts the jobs in reverse order (by job name).
+.IP
+The -R flag rebuilds the jobs table and reindexes each job; this
+is necessary after upgrading to 98.2. "p4 jobs -R" requires
+superuser access granted by "p4 protect".
+.TP
+.B p4 jobspec
+.TP
+.B p4 jobspec -o
+.TP
+.B p4 jobspec -i
+.IP
+Jobspec edits the template that specifies the format of jobs.
+This format is used by "p4 job" when jobs are entered or updated,
+and by "p4 jobs" and "p4 describe" when jobs are displayed.
+.IP
+Jobspec brings up a form with the following fields:
+.RS
+.TP
+Fields:
+A list of the fields maintained for each job, one
+line per field. Each line has five words: code, name,
+data-type, len, and field-type.
+.RE
+"code" is a unique integer identifier for storing
+the data of the field. Job codes must be between
+101 and 199.
+"name" is the name of the field for the job.
+"data-type" indicates the format of the field:
+.IP
+word: a single word (any value)
+date: a date/time field
+select: one of a set of words
+line: a one-liner
+text: a block of text
+"len" is the recommended character length of a
+display box for the field. If 0, a text box is
+assumed.
+"field-type" indicates how to handle the setting of
+the field:
+.IP
+optional: no default, and not required to be present
+default: default provided, still not required
+required: default provided, value must be present
+once: set once to the default and never changed
+always: always reset to the default upon saving
+.RS
+.TP
+Values:
+A list of "select" fields and the values those fields
+can have. Each line has two words: the field name and
+the values list, with individual values separated by
+"/" (no spaces).
+.RE
+.RS
+.TP
+Presets:
+A list of fields and their default values, for fields
+whose "setting" flag is other than "optional". Each
+line has two words: the field name and the default
+value. If the value has spaces, it must be enclosed
+in double quotes. The following special defaults are
+recognized:
+.RE
+.IP
+$user: the user entering the job
+$now: the current date
+$blank: the words "<enter description here>"
+.RS
+.TP
+Comments:
+textual comments to be included at the top of each
+job specification, to help the user fill out the form.
+Each line must begin with the comment character "#".
+.RE
+.IP
+Certain field codes have special significance:
+.IP
+code 101, required: the job name
+code 102, optional: the job status
+code 103, optional: the user who created the job
+code 104, optional: the date the job was created
+code 105, optional: the description
+.IP
+If there is a job status field (102), "p4 submit" and "p4 fix"
+will set it to "closed" for any jobs being fixed by the change.
+.IP
+Fields 102-105 are used by "p4 describe" and "p4 jobs" to
+display a job summary. Any missing fields simply will not
+appear in the summary line.
+.IP
+If field 105 is present, it is assumed to be a description,
+which is used by "p4 change" and "p4 submit" to annotate the
+list of jobs to be fixed by the change being created.
+.IP
+When updating the jobspec after jobs have been entered, certain
+limitations apply:
+.IP
+Data is stored according to its code. Fields can be renamed
+by keeping the same code. Removing a code can abandon the
+associated data stored for the code.
+.IP
+Changing the definition of a code (e.g. from "text" to "word")
+can require users to bring jobs into the new format as they
+are edited.
+.IP
+The -o flag causes the job template to be written to the standard
+output. The user"s editor is not invoked.
+.IP
+The -i flag causes a job template to be read from the standard
+input. The user"s editor is not invoked.
+.IP
+"p4 jobspec" requires superuser access granted by "p4 protect".
+.TP
+.B p4 label [ -f -t template ] name
+.TP
+.B p4 label -d [ -f ] name
+.TP
+.B p4 label -o [ -t template ] name
+.TP
+.B p4 label -i [ -f ]
+.IP
+Create a new label specification or edit an existing label
+specification. A name is required. The specification form
+is put into a temporary file and the editor (given by the
+environment variable $P4EDITOR) is invoked.
+.IP
+The label specification form contains the following fields:
+.RS
+.TP
+Label:
+The label name (read only.)
+.RE
+.RS
+.TP
+Owner:
+The user who created this label. Can be changed.
+.RE
+.RS
+.TP
+Update:
+The date this specification was last modified.
+.RE
+.RS
+.TP
+Access:
+The date of the last "labelsync" or use of "@label"
+on this label.
+.RE
+.RS
+.TP
+Description:
+A short description of the label (optional).
+.RE
+.RS
+.TP
+Options:
+Flags to change the label behavior.
+.RE
+.RS
+.RS
+.TP
+locked
+Allows only the label owner to change its
+specification. Prevents the label from
+being deleted. Prohibits "p4 labelsync".
+.RE
+.RE
+.RS
+.TP
+View:
+A mapping to select files from the depot.
+The default view selects all depot files.
+.RE
+.IP
+A label definition is used only by the "p4 labelsync" command.
+Only the owner of a label may run labelsync on that label.
+A label that has its Options: set to "locked" cannot be updated.
+.IP
+Flag -d causes the named label to be deleted, as long as it is
+not locked. The -f flag forces the delete.
+.IP
+The -o flag causes the named label specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a label specification to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+The -t flag constructs the label"s view by copying the named
+template label"s view, instead of using the existing view or
+creating a new default view.
+.IP
+The -f flag allows the superuser to delete any label; normally
+locked labels can only be deleted by their owner. -f also allows
+the last modified date to be set.
+.TP
+.B p4 labels [ file[revrange] ]
+.IP
+Reports the list of all labels currently known to the system.
+.IP
+If files are specified, "p4 labels" limits its report to labels
+that contain those files. If the file specification includes
+a revision range, "p4 labels" limits its report to labels that
+contain those particular revisions. See "p4 help revisions"
+for help specify revisions.
+.TP
+.B p4 labelsync [ -a -d -n ] -l label [ file[revRange] ... ]
+.IP
+Labelsync causes the named label to reflect the current contents
+of the client. It records the last revision of each file taken
+onto the client. The label"s name can subsequently be used in
+a revision specification as @label to refer to the revision of
+a file as stored in the label.
+.IP
+Without a file argument, labelsync causes the label to reflect the
+contents of the whole client, by adding, deleting, and updating the
+label. If a file is given, labelsync updates only that named file.
+.IP
+If the file argument includes a revision specification, then that
+revision is used instead of the revision taken by the client.
+See "p4 help revisions" for help specifying revisions.
+.IP
+If the file argument includes a revision range specification, then
+only files selected by the revision range are updated, and the
+highest revision in the range is used.
+.IP
+The -a flag causes labelsync to add the named file to the label;
+no files will be deleted from the label.
+.IP
+The -d deletes the named file from the label, regardless of revision.
+.IP
+The -n flag lists how the label would be affected, but doesn"t
+actually update the label.
+.IP
+Only the owner of a label may run labelsync on that label.
+A label that has its Options: set to "locked" cannot be updated.
+.TP
+.B p4 lock [ -c changelist# ] [ file ... ]
+.IP
+The open files named are locked in the depot, preventing any
+user other than the current user on the current client from
+submitting changes to the files. If a file is already locked
+then the lock request is rejected. If no file names are given
+then lock all files currently open in the changelist number given
+or in the "default" changelist if no changelist number is given.
+.TP
+.B p4 logger [ -c sequence# ] [ -t counter ]
+.IP
+Dumps the event log, which notes updates to changes and jobs, for
+use with defect tracking integration. The event log is enabled
+by setting the counter "logger" (to 0) with "p4 counter". Each
+event has a sequence number. The presence of an entry in the log
+doesn"t guarantee that the named entity has changed.
+.IP
+If a sequence# is given with -c, only events since that number are
+listed. If a counter is given with -t, only events since the
+number of that counter are listed. If both are given, then the
+counter is updated to the sequence number and nothing is output.
+If the update brings the counter to the highest sequence number
+in the log, the log is cleared. This generally means that only
+one user can really make use of this option.
+.IP
+"p4 logger" is not meant as an end-user command. It exists to
+support propagating information to an external defect tracking
+system.
+.IP
+"p4 logger -c" requires "review" access granted by "p4 protect".
+.TP
+.B p4 obliterate [ -y -z ] file[revRange] ...
+.IP
+Obliterate removes files and their history from the server in a
+way that they won"t come back. (See "p4 delete" for the non-
+destructive way to delete a file.) It retrieves space used by those
+files in the archive and then clears the files from all lists
+maintained by the server. Files in client workspaces are not
+affected, except that Perforce will no longer recognize them
+as being under its control.
+.IP
+Obliterate carefully undoes the lazy copies made when "p4 integrate"
+creates a branch. Because of this, it is possible that obliterating
+files will not recover any space.
+.IP
+If the file argument has a revision, then only that revision is
+obliterated. If the file argument has a revision range, then only
+the revisions in that range are obliterated. See "p4 help revisions"
+for help.
+.IP
+The -y flag instruct obliterate to do its work. Otherwise, it
+just displays what it would do.
+.IP
+The -z flag restricts obliterate to undoing lazy copies. It does
+not actually remove any files or metadata, but creates physical
+copies of previously lazy copies, and as such, is likely to increase
+space use on the server. Use this on the source files to ensure that
+in the database no other files refer to the named files.
+.IP
+"p4 obliterate" requires superuser access granted by "p4 protect".
+.TP
+.B p4 opened [ -a -c changelist# ] [ file ... ]
+.IP
+Shows files currently opened for pending changelists or indicates
+for the specified individual files whether they are currently opened.
+If no file names are given, all files open on the current client
+are listed.
+.IP
+The -a flag lists opened files in all clients. Normally only files
+opened by the current client are listed.
+.IP
+The -c changelist# flag restricts the list to files opened under
+the given changelist#. Normally files in any changelist (include the
+"default") are listed.
+.TP
+.B p4 passwd [ -O oldPassword -P newPassword ] [ user ]
+.IP
+"p4 passwd" sets the user"s password on the server.
+.IP
+Once a password is set for a user on the server, then in order for
+that user to invoke any Perforce client commands the same password
+must be set on the client in the environment variable $P4PASSWD.
+(On Windows, "p4 passwd" sets this as well.)
+.IP
+"p4 passwd" prompts for both the old password and the new password
+with character echoing turned off. Setting the password to an
+empty string deletes the password.
+.IP
+The -O flag provides the old password, avoiding prompting.
+.IP
+The -P flag provides the new password, avoiding prompting.
+.IP
+Setting the password of someone other than the current user
+requires superuser access granted by "p4 protect". In this case
+"p4 passwd" does not prompt for the old password.
+.TP
+.B p4 print [ -o localFile -q ] file[revRange] ...
+.IP
+Retrieve the contents of a depot file to the client"s standard
+output. The client"s have list is not affected. If file is
+specified as a client file name, the client view is used to
+find the corresponding depot file.
+.IP
+If the file argument has a revision, then all files as of that
+revision are printed. If the file argument has a revision range,
+then only files selected by that revision range are printed, and
+the highest revision in the range is used for each file. Normally,
+the head revision is printed. See "p4 help revisions" for help
+specifying revisions.
+.IP
+The -o localFile flag redirects the output to the named file on
+the client filesystem. In this case, at most one file is written.
+.IP
+The -q flag suppresses the initial line that displays the file name
+and revision.
+.TP
+.B p4 protect
+.TP
+.B p4 protect -o
+.TP
+.B p4 protect -i
+.IP
+"p4 protect" edits the protections table using an ASCII form.
+Once protections are in place, only a user with superuser access
+may use the "p4 protect" command.
+.IP
+Each line contains a protection mode, a group/user indicator, the
+group/user name, client host id and a depot file path pattern.
+A user gets the highest privilege granted on any line.
+.RS
+.TP
+Note:
+remote depot accesses are made using the pseudo-user "remote";
+access by other servers can be controlled by granting appropriate
+permissions to the "remote" user.
+.RE
+.RS
+.TP
+Mode:
+The permission being granted. Each permission includes
+all the permissions above it, except for "review".
+.RE
+list - users can see names but not contents of files;
+users can see all non-file related metadata
+(clients, users, changelists, jobs, etc.)
+read - users can sync, diff, and print files
+open - users can add, edit, delete, and integrate files
+write - users can submit open files
+super - allows access to the "p4 protect" command
+review - allows access to the "p4 review" command;
+implies read access
+.IP
+Group/User indicator: either "group" or "user".
+.RS
+.TP
+Name:
+A Perforce group or user name; may be wildcarded.
+.RE
+.RS
+.TP
+Host:
+The IP address of a client host; may be wildcarded.
+.RE
+.RS
+.TP
+Path:
+The part of the depot being granted access.
+.RE
+.IP
+The -o flag causes the protection table to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes the protection table to be read from the
+standard input. The user"s editor is not invoked.
+.TP
+.B p4 integrate from to
+.TP
+.B p4 delete from
+.TP
+.B p4 submit
+.IP
+Perforce does not support a single "rename" command, but files can
+be renamed by branching one file into another and then deleting the
+original file.
+.IP
+The "from" and "to" file arguments may include wildcards as long as
+they are matched.
+.IP
+Integrating from files require read access to the files, but deleting
+them requires write access.
+.IP
+For further information, see the help for the individual commands.
+.TP
+.B p4 reopen [ -c changelist# ] [ -t filetype ] file ...
+.IP
+Reopen takes an already opened file and reopens it for the current
+user, optionally changing its changelist or filetype.
+.IP
+The changelist must have previously been created with "p4 change"
+or may be the "default" changelist.
+.IP
+See "p4 help filetypes" for a list of types.
+.TP
+.B p4 resolve [ -af -am -as -at -ay -f -n -t -v ] [ file ... ]
+.IP
+Resolve handles file integrations through an interactive dialog.
+If no file is named all open files requiring integration will
+be acted upon.
+.IP
+Perforce detects the occurrence of parallel changes, requiring
+a merger of changes and resolution of potential conflicts.
+Resolution may be either textual or non-textual.
+Textual resolution occurs when there are parallel edits to
+related text files. In this case it may be possible to comingle
+edits meaningfully. Non-textual resolution occurs when at least
+one of the related files is binary, or the change actions
+themselves are incompatible, such as when one file has been
+deleted while the other file has been edited.
+.IP
+For textual resolution you are provided with a file containing a
+merger of your changes in the working file on the client
+("yours") with the parallel changes that have been made
+in the depot ("theirs"), based on a common original ancestor
+revision of the two parallel versions ("base").
+.IP
+The display presents a count of change sections of the merged
+text according to whether they are:
+.IP
+yours change is only in your working revision (no conflict)
+theirs change is only in the depot revision (no conflict)
+both same text added or changed in both (no conflict)
+conflicting conflicting changes between the yours and theirs
+.IP
+If the count for "conflicts" is non-zero then the merged
+version will contain integration marks bracketing alternative
+changes at places in the text where conflicts occur. You
+must edit the file to resolve the conflict and remove the
+integration marks.
+.IP
+For non-textual resolution no merge file is created and you are given
+the choice of choosing "yours" or "theirs".
+.IP
+Choices for action include:
+.RS
+.TP
+Accept:
+
+at Keep only changes to their file.
+ay Keep only changes to your file.
+* am Keep merged file.
+* a Keep autoselected file.
+.RE
+.RS
+.TP
+Diff:
+
+* dt See their changes alone.
+* dy See your changes alone.
+* dm See merged changes.
+d Diff your file against merged file.
+.RE
+.RS
+.TP
+Edit:
+
+et Edit their file (read only).
+ey Edit your file (read/write).
+* e Edit merged file (read/write).
+.RE
+.RS
+.TP
+Misc:
+
+* m Run "$P4MERGE base theirs yours merged".
+s Skip this file.
+h Print this help message.
+^C Quit the resolve operation.
+.RE
+.IP
+Options marked (*) appear only for textual resolution.
+.IP
+Any form of Accept marks the resolution complete (to the users
+satisfaction). Skip leaves the integration marked unresolved
+allowing you to return to it at a later time.
+.IP
+The Merge option allows you to invoke your own integration and
+conflict resolution utility (named in the $P4MERGE environment
+variable). This utility is expected to replace the existing
+merged file with a new one.
+.IP
+The -am flag puts "p4 resolve" into automatic mode: if there are
+conflicts, the file is skipped; if there are no conflicts and
+yours hasn"t changed it accepts theirs; if theirs hasn"t changed
+it accepts yours; if both yours and theirs have changed it accepts
+the merge. Files that have no base for merging (e.g. binary files)
+are always skipped.
+.IP
+The -af flag forces "p4 resolve" in automatic mode to accept the
+merged file even if there are conflicts.
+.IP
+The -as flag performs a "safe" automatic resolve, accepting only
+files that have either your changes or their changes, but not both.
+Files with changes to both yours and theirs are skipped.
+.IP
+The -at and -ay flags perform an automatic resolve that skips the
+merging. Instead it automatically accepts their (-at) or your (-ay)
+version of the file. The -at flag should be used with care, as
+it overwrites any changes made to the file in the client workspace.
+.IP
+The -f flag allows previously resolved files to be resolved again.
+Normally, once files have been resolved then "p4 resolve" won"t
+display them again. This is the proper way to re-edit files if the
+results of an initial "p4 resolve" are not satisfactory.
+.IP
+The -n flag lists the integrations which would be performed
+without actually putting the user into the resolution dialog.
+.IP
+The -t flag forces "p4 resolve" to attempt a textual merge, even
+for files with non-text (binary) types.
+.IP
+The -v flag causes "p4 resolve" to put in markers for all changes,
+not just those in conflict. The markers must be edited out before
+the merged file can be accepted.
+.TP
+.B p4 resolved [ file ... ]
+.IP
+Resolved shows integrations that have already been resolved
+but not yet submitted. Use "p4 resolve -n" to see unresolved
+integrations and "p4 integrated" to see already submitted
+integrations.
+.TP
+.B p4 revert [ -a -c changelist# ] file ...
+.IP
+Revert an open file back to the revision previously synced from
+the depot, discarding any pending changelists or integrations that
+have been made. This command requires naming files explicitly.
+After running revert the named files will no longer be locked
+or open.
+.IP
+The -a flag tells "p4 revert" to revert only those files which
+are opened for edit or integrate and are unchanged or missing.
+Files with pending integration records are left open. With the
+-a flag, the file arguments are optional.
+.IP
+The -c flag limits "p4 revert" to files opened under the given,
+pending changelist.
+.TP
+.B p4 review [ -c changelist# ] [ -t counter ]
+.IP
+"p4 review" lists changelists that have not been reviewed before,
+as tracked by the named counter. If the counter is not given,
+"p4 review" lists all changelists. (If a changelist# and counter
+are given, "p4 review" sets the counter to that changelist# and
+produces no output. This functionality has been superceded by the
+"p4 counter" command.)
+.IP
+"p4 review" is not meant as an end-user command. It exists to
+support an automated change review daemon.
+.TP
+.B p4 reviews [ -c changelist# ] [ file ... ]
+.IP
+"p4 reviews" lists all users who have subscribed to review the named
+files, the files in the numbered changelist, or all files by default.
+Users subscribe to review files via the "p4 user" command.
+.TP
+.B p4 set [ -s -S service ] [ var=[value] ]
+.IP
+"p4 set" sets the registry variables used by Perforce on Windows
+platforms. Normally, the variable "var" is set to "value".
+If "value" is missing, the variable "var" is unset. Without
+any arguments at all, "p4 set" list variable settings.
+.IP
+The -s flag causes "p4 set" to set variables for the whole system
+rather than for the user. You must have NT administrator powers
+to use this.
+.IP
+The -S service flag causes "p4 set" to set variables for the named
+service. You must have NT administrator powers to use this.
+.IP
+Currently, registry variable entries may be overridden by environment
+variables and (in some cases) flags on the command line.
+See "p4 help environment" for a list of environment/registry variables.
+.TP
+.B p4 submit [ -s ]
+.TP
+.B p4 submit [ -s ] files
+.TP
+.B p4 submit -c changelist#
+.TP
+.B p4 submit -i [ -s ]
+.IP
+"p4 submit" commits a pending changelist and its files to the depot.
+.IP
+With no argument "p4 submit" attempts to submit all files in the
+"default" changelist. Submit provides the user with a dialog
+similar to "p4 change" so the user can compose a changelist
+description. In this dialog the user is presented with the list
+of files open in changelist "default". Files may be deleted from
+this list but they cannot be added. (Use an open command (edit,
+add, delete) to add additional files to a changelist.)
+.IP
+If a (single) file pattern is given, only those files in
+the "default" changelist that match the pattern will be submitted.
+.IP
+The -c flag submits the numbered pending changelist that has been
+previously created with "p4 change" or a failed "p4 submit".
+.IP
+The -i flag causes a changelist specification (including files to be
+submitted) to be read from the standard input. The user"s editor
+is not invoked.
+.IP
+The -s flag extends the list of jobs to include the fix status
+for each job, which becomes the job"s status when the changelist
+is committed. See "p4 help change" for more notes on this option.
+.IP
+Before committing a changelist submit locks all associated files not
+already locked. If any file cannot be locked, or if the submit
+fails for any other reason the files are left open in a newly
+created pending changelist.
+.IP
+Submit is guaranteed to be atomic. Either all files will be
+updated in the depot as a unit or none will be.
+.TP
+.B p4 sync [ -f -n ] [ file[revRange] ... ]
+.IP
+Sync updates the client workspace to reflect its current view (if
+it has changed) and the current contents of the depot (if it has
+changed). The client view is used to map client file names to
+depot file names and vice versa.
+.IP
+Sync adds files that are in the client view but which have not been
+retrieved before. Sync deletes previously retrieved files which
+are no longer in the client view or have been deleted from the
+depot. Sync updates files which are still in the client view and
+which have been updated in the depot.
+.IP
+Normally, sync affects all files in the client workspace. If file
+arguments are given, sync limits its operation to those files.
+The file arguments may contain wildcards.
+.IP
+If the file argument includes a revision specifier, then the given
+revision is retrieved. Normally, the head revision is retrieved.
+See "p4 help revisions" for help specifying revisions.
+.IP
+If the file argument includes a revision range specification, then
+only files selected by the revision range are updated, and the
+highest revision in the range is used.
+.IP
+Normally, sync will not clobber files in the client workspace that
+the user has made writable. Setting the "clobber" option in the
+client spec disables this safety check.
+.IP
+The -f flag forces resynchronization even if the client already
+has the file, and clobbers writable files. This flag doesn"t affect
+open files.
+.IP
+The -n flag causes sync not to update the client workspace, but to
+display what normally would be updated.
+.TP
+.B p4 triggers
+.TP
+.B p4 triggers -o
+.TP
+.B p4 triggers -i
+.IP
+"p4 triggers" edits the table of pre-submit triggers.
+.IP
+Triggers are user-defined commands that are run on the server
+during changelist submission to validate the changelist. The
+commands are run on the server after the changelist is created
+and the files are locked but before any files are transferred.
+Thus triggers cannot validate the contents of files being submitted.
+.IP
+The trigger form has a single entry "Triggers", followed by any
+number of trigger lines. Triggers are executed in the order listed
+and if a trigger fails subsequent triggers are not run. A trigger
+succeeds if the command executed exits 0 and fails otherwise.
+If it fails, the command"s standard output (not error output)
+is used as the text of the trigger failure error message.
+.IP
+Each trigger line contains a trigger name, a depot file path
+pattern, and a command to run:
+.RS
+.TP
+Name:
+The name of the trigger. A run of the same trigger
+name on contiguous lines is treated as a single trigger,
+so that multiple paths may be specified. Only the
+command of the first such trigger line is used.
+.RE
+.RS
+.TP
+Path:
+Files which will cause the trigger to be run. This
+is a file pattern and may be an exclusion mapping (-pattern)
+to exclude files.
+.RE
+.RS
+.TP
+Command:
+The command to run to validate the changelist. If the
+command contains spaces, the whole command must be
+quoted. The following variables are expanded in the
+command string:
+.RE
+.IP
+%changelist% -- the changelist being submitted
+%client% -- the client submitting the changelist
+%clienthost% -- the hostname of the client
+%clientip% -- the IP address of the client
+%serverhost% -- the hostname of the server
+%serverip% -- the IP address of the server
+%serverport% -- the IP address:port of the server
+%serverroot% -- the value of the server"s $P4ROOT
+%user% -- the user submitting the changelist
+More information can be gathered about the changelist
+being submitted by running "p4 describe %changelist%".
+.IP
+The -o flag causes the trigger table to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes the trigger table to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+"p4 triggers" requires superuser access granted by "p4 protect".
+.TP
+.B p4 typemap
+.TP
+.B p4 typemap -o
+.TP
+.B p4 typemap -i
+.IP
+"p4 typemap" edits a name-to-type mapping table for "p4 add",
+which consults the table to select a file"s filetype based on
+its name.
+.IP
+The typemap form has a single entry "TypeMap", followed by any
+number of typemap lines. Each typemap line contains a filetype
+and a depot file path pattern:
+.RS
+.TP
+Filetype:
+See "p4 help filetypes" for a list of valid filetypes.
+.RE
+.RS
+.TP
+Path:
+Names to be mapped to the filetype. This is a file
+pattern and may be an exclusion mapping (-pattern)
+to exclude files. Note to match all files anywhere
+in the depot hierarchy, the pattern must begin with
+//..., and to match any file with a given suffix you
+must either specify "//.../*.suffix" or "//....suffix"
+(four dots).
+.RE
+.IP
+As with all mappings, later entries override earlier entries.
+If no matching entry is found in the table, "p4 add" senses the
+file"s filetype by examining the file"s contents and execution
+permission bits.
+.IP
+The -o flag causes the typemap table to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes the typemap table to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+"p4 typemap" requires superuser access granted by "p4 protect".
+.TP
+.B p4 unlock [ -c changelist# ] [ file ... ]
+.IP
+"p4 unlock" releases a lock on an open file in a pending changelist.
+If the file is open in a specific pending changelist other than
+"default", then the -c flag is required to specify the pending
+changelist. If no file name is given then all files in the
+designated changelist are unlocked.
+.TP
+.B p4 user [ -f ] [ name ]
+.TP
+.B p4 user -d [ -f ] name
+.TP
+.B p4 user -o [ name ]
+.TP
+.B p4 user -i [ -f ]
+.IP
+Create a new user specification or edit an existing user
+specification. The specification form is put into a temporary
+file and the editor (given by the environment variable $P4EDITOR)
+is invoked.
+.IP
+Normally, a user specification is created automatically the
+first time the user invokes any client command that can update
+the depot. The "p4 user" command is generally used to edit the
+user"s reviewing subscription list for change review.
+.IP
+The user specification form contains the following fields:
+.RS
+.TP
+User:
+The user name (read only).
+.RE
+.RS
+.TP
+Email:
+The user"s email address (user@client default).
+.RE
+.RS
+.TP
+Update:
+The date the specification was last modified (read only).
+.RE
+.RS
+.TP
+Access:
+The date the user last issued a client command.
+.RE
+.IP
+FullName: The user"s real name.
+.IP
+JobView: Selects jobs to be presented at changelist creation.
+These are the jobs that can be closed automatically
+upon changelist submission. See "p4 help jobview"
+for a description of jobview syntax.
+.RS
+.TP
+Reviews:
+The subscription list for change review. You may
+use wildcards:
+... matches any characters including /
+* matches any character except /
+There may be any number of review lines.
+.RE
+.RS
+.TP
+Password:
+The user"s password. See also "p4 help passwd".
+.RE
+.IP
+The -d flag deletes the named user, but only if the user is not
+the owner of any branches, clients, jobs, labels, or opened files.
+.IP
+The -o flag causes the named user specification to be written
+to the standard output. The user"s editor is not invoked.
+.IP
+The -i flag causes a user specification to be read from the
+standard input. The user"s editor is not invoked.
+.IP
+The -f flag allows the superuser to delete or modify any user;
+normally users can only be deleted or modified by themselves.
+-f also allows the last modified date to be set.
+.TP
+.B p4 users [ user ... ]
+.IP
+Reports the list of all users, or those users matching the argument,
+currently known to the system. The report includes the last time
+each user accessed the system.
+.TP
+.B p4 verify [ -q -u -v ] file[revRange] ...
+.IP
+"p4 verify" reports for each revision of the named files the
+revision specific information and an MD5 digest (fingerprint)
+of the revision"s contents. See "p4 help revisions" for help
+specifying revisions.
+.IP
+By default, "p4 verify" computes and displays the digest of each
+revision. If a revision cannot be reproduced (e.g. if the file
+is missing from the archive), the revision"s output line ends with
+MISSING! If there is a saved digest, "p4 verify" compares it with
+the computed one. If they differ the output line ends with BAD!
+.IP
+The -u flag causes "p4 verify" to compute and save the digest
+for each revision that has no saved digest. Revisions already
+with saved digests are skipped.
+.IP
+The -v flag forces "p4 verify" to compute and save the digest
+for each revision, even if it already has a saved digest. This
+can be used to update the saved digest if the archive was changed
+deliberately.
+.IP
+The -q flag instructs "p4 verify" to operate quietly. The only
+output would be errors from mismatched digests or errors due to
+unreproducible revisions.
+.IP
+The following commands will compute digests for revisions without
+saved digests and then verify the first and head revisions of all
+files. Verifying revision #1 is useful for text files because
+of their reverse delta storage format: corruption of any revision
+will be reflected in revision #1.
+.RS
+.RS
+.TP
+p4
+verify -qu //...
+.RE
+.RE
+.RS
+.RS
+.TP
+p4
+verify -q #1,#1
+.RE
+.RE
+.RS
+.RS
+.TP
+p4
+verify -q #head,#head
+.RE
+.RE
+.IP
+Saved digests are also used by "p4 diff" to avoid having to
+compute them each time.
+.IP
+"p4 verify" requires superuser access granted by "p4 protect".
+.TP
+.B p4 where [ file ... ]
+.IP
+Where shows how the named files map through the client view.
+For each argument, three names are produced: the name in the
+depot, the name on the client in Perforce syntax, and the name
+on the client in local syntax.
+.IP
+If no file is given, the mapping for "..." (all files in the
+current directory and below) is shown.
+.IP
+Note that "p4 where" does not determine where any real files are.
+It only computes where they should be according to the client view.