2255 lines
71 KiB
Groff
2255 lines
71 KiB
Groff
.\" 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.
|