diff options
Diffstat (limited to 'development/p4/p4.man')
| -rw-r--r-- | development/p4/p4.man | 2254 |
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. |