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