development/p4: Updated for version 2016.2.1487173.

Signed-off-by: David Spencer <idlemoor@slackbuilds.org>

3 files changed, 4 insertions, 2258 deletions

diff --git a/development/p4/p4.SlackBuild b/development/p4/p4.SlackBuild
index a7166225bc..60ab625e25 100644
--- a/development/p4/p4.SlackBuild
+++ b/development/p4/p4.SlackBuild
@@ -5,7 +5,7 @@
 # Modified by David Sullins <david.sullins@gmail.com>
 
 PRGNAM=p4
-VERSION=${VERSION:-2016.2.1468155}
+VERSION=${VERSION:-2016.2.1487173}
 BUILD=${BUILD:-1}
 TAG=${TAG:-_SBo}
 
diff --git a/development/p4/p4.info b/development/p4/p4.info
index 9da6918d20..4acd23c641 100644
--- a/development/p4/p4.info
+++ b/development/p4/p4.info
@@ -1,10 +1,10 @@
 PRGNAM="p4"
-VERSION="2016.2.1468155"
+VERSION="2016.2.1487173"
 HOMEPAGE="http://www.perforce.com/"
 DOWNLOAD="http://www.perforce.com/downloads/perforce/r16.2/bin.linux26x86/p4"
-MD5SUM="91baac1417bd5d4109093a6118be16f0"
+MD5SUM="be23b2b89661b33f5da542b455d1b497"
 DOWNLOAD_x86_64="http://www.perforce.com/downloads/perforce/r16.2/bin.linux26x86_64/p4"
-MD5SUM_x86_64="6a30d917f5f13ed1e2938429fccb5ca8"
+MD5SUM_x86_64="30de597d0a94a10c8464e0268bc39b2a"
 REQUIRES=""
 MAINTAINER="David Sullins"
 EMAIL="david.sullins@gmail.com"
diff --git a/development/p4/p4.man b/development/p4/p4.man
deleted file mode 100644
index 842165a697..0000000000
--- a/development/p4/p4.man
+++ /dev/null
@@ -1,2254 +0,0 @@
-.\" 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.