p4api.net
The StrDictListIterator represents the iterator functions exposed by
the P4 bridge dll to allow the client to read structured (tagged) data.
It is not exposed outside the p4.net assembly as the P4Server class
translates the raw data into a .NET array list of hash tables.
Simple calls used to read key:value pairs from a StrDict object
referenced by a pointer returned from the bridge
Error severity levels.
Unknown
nothing yet
something good happened
something not good happened
user did something wrong
system broken -- nothing can continue
Used to turnoff exceptions
Class used to return a single error or warning from the bridge dll.
How severe is the error
Generic code for the error
Descriptive error message
Create a new ClientError
Create a new ClientError
Format the error in the form [ErrorLevel] Message
Class used to return a list of errors and warnings returned by a command.
Read an error list from the server by traversing the linked list.
Perforce server
First error in the list
Create a list of a single error
Error
Create a list of a single error
Error message
Severity level
Read the error list from the server
Create a list from the current error results on the server
Perforce Server
Cast the errors to a String[]
the list to cast
Cast the errors to a String. Each error is separated by \r\n
the list to cast
Used to wrap a byte[] that is pinned in memory to pass down to the dll.
In general, since .NET does not natively support marshaling Strings to
UTF-8 for char * parameters, we must do our own encoding of the
strings into byte[], pin them, pass them to the dll, and then free the
pinned memory on return. This class wraps that process with an
IDisposable object to ensure the memory is freed after the call.
Class containing the DLL imports for the P4Bridge DLL.
Wrapper for an array of PinnedByteArrays, used to wrap the arg list
passed to a command to make sure the pinned memory is freed.
Represents a Perforce server and connection.
Get server information.
Information about a connection's client-side application context.
p4 help info
info -- Display client/server information
p4 info [-s]
Info lists information about the current client (user name,
client name, applicable client root, client current directory,
and the client IP address) and some server information (server
IP address, server root, date, uptime, version and license data).
The -s option produces 'short' output that omits any information
that requires a database lookup such as the client root).
To get the server root:
ServerMetaData s = rep.GetServerMetaData(null);
string root = s.Root;
To get the server case handling:
ServerMetaData s = rep.GetServerMetaData(null);
bool caseSensitive = s.CaseSensitive;
Create a new branch in the repository.
Branch specification for the new branch
The '-i' flag is required when creating a new branch
The Branch object if new branch was created, null if creation failed
p4 help branch
branch -- Create, modify, or delete a branch view specification
p4 branch [-f] name
p4 branch -d [-f] name
p4 branch [ -S stream ] [ -P parent ] -o name
p4 branch -i [-f]
A branch specification ('spec') is a named, user-defined mapping of
depot files to depot files. It can be used with most of the commands
that operate on two sets of files ('copy', 'merge', 'integrate',
'diff2', etc.)
Creating a branch spec does not branch files. To branch files, use
'p4 copy', with or without a branch spec.
The 'branch' command puts the branch spec into a temporary file and
invokes the editor configured by the environment variable $P4EDITOR.
Saving the file creates or modifies the branch spec.
The branch spec contains the following fields:
Branch: The branch spec name (read only).
Owner: The user who created this branch spec. Can be changed.
Update: The date this branch spec was last modified.
Access: The date of the last command used with this spec.
Description: A description of the branch spec (optional).
Options: Flags to change the branch spec behavior. The defaults
are marked with *.
locked Permits only the owner to change the spec.
unlocked * Prevents the branch spec from being deleted.
View: Lines mapping of one view of depot files to another.
Both the left and right-hand sides of the mappings refer
to the depot namespace. See 'p4 help views' for more on
view syntax.
New branch specs are created with a default view that maps all depot
files to themselves. This view must be changed before the branch
spec can be saved.
The -d flag deletes the named branch spec.
The -o flag writes the branch spec to standard output. The user's
editor is not invoked.
The -i flag causes a branch spec to be read from the standard input.
The user's editor is not invoked.
The -f flag enables a user with 'admin' privilege to delete the spec
or set the 'last modified' date. By default, specs can be deleted
only by their owner.
A branch spec can also be used to expose the internally generated
mapping of a stream to its parent. (See 'p4 help stream' and 'p4
help streamintro'.)
The -S stream flag will expose the internally generated mapping.
The -P flag may be used with -S to treat the stream as if it were a
child of a different parent. The -o flag is required with -S.
To create a branch spec [-i]:
BranchSpec newBranchSpec = new BranchSpec();
newBranchSpec.Id = "newBranchSpec";
newBranchSpec.Owner = "admin";
newBranchSpec.Description = " created by perforce";
newBranchSpec.ViewMap = new ViewMap();
string v0 = "//depot/main/... //depot/rel1/...";
string v1 = "//depot/main/... //depot/rel2/...";
string v2 = "//depot/dev/... //depot/main/...";
newBranchSpec.ViewMap.Add(v0);
newBranchSpec.ViewMap.Add(v1);
newBranchSpec.ViewMap.Add(v2);
Options opts = new Options(BranchSpecCmdFlags.Input);
_repository.CreateBranchSpec(newBranchSpec, opts);
Create a new branch in the repository.
Branch specification for the new branch
The Branch object if new branch was created, null if creation failed
To create a basic branch spec:
BranchSpec newBranchSpec = new BranchSpec();
newBranchSpec.Id = "newBranchSpec";
newBranchSpec.ViewMap = new ViewMap();
string v0 = "//depot/main/... //depot/rel1/...";
newBranchSpec.ViewMap.Add(v0);
_repository.CreateBranchSpec(newBranchSpec);
Update the record for a branch in the repository
Branch specification for the branch being updated
The Branch object if new depot was saved, null if creation failed
To append a view to an existing branch spec:
BranchSpec updateBranchSpec = _repository.GetBranchSpec("newBranchSpec");
string v0 = "\"//depot/main/a file with spaces.txt\" \"//depot/rel1/a file with spaces.txt\"";
updateBranchSpec.ViewMap.Add(v0);
_repository.UpdateBranchSpec(updateBranchSpec);
To lock a branch spec:
BranchSpec updateBranchSpec = _repository.GetBranchSpec("newBranchSpec");
updateBranchSpec.Locked = true;
_repository.UpdateBranchSpec(updateBranchSpec);
Get the record for an existing branch from the repository.
Branch name
The Branch object if branch was found, null if creation failed
To get a branch spec:
BranchSpec getBranchSpec = _repository.GetBranchSpec("newBranchSpec");
Get a list of branches from the repository
A list containing the matching branches
p4 help branches
branches -- Display list of branch specifications
p4 branches [-t] [-u user] [[-e|-E] nameFilter -m max]
Lists branch specifications. (See 'p4 help branch'.)
The -t flag displays the time as well as the date.
The -u user flag lists branch specs owned by the specified user.
The -e nameFilter flag lists branch specs with a name that matches
the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes
the matching case-insensitive.
The -m max flag limits output to the specified number of branch specs.
To get all branches and include timestamps [-t] (WARNING, will fetch all branches from the repository):
Options opts = new Options(BranchSpecsCmdFlags.Time, "", "", -1);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
To get branches owned by 'Bob' [-u]:
Options opts = new Options(BranchSpecsCmdFlags.None, "Bob", "", -1);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
To get the first 10 branches that start with the capital letter 'A' [-m] [-e]:
Options opts = new Options(BranchSpecsCmdFlags.None, "", "A*", 10);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
To get the first 10 branches that start with the letter 'A' case insensitive [-m] [-E]:
Options opts = new Options(BranchSpecsCmdFlags.IgnoreCase, "", "A*", 10);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
Delete a branch from the repository
The branch to be deleted
The '-f' and '-d' flags are valid when deleting an
existing branch
To delete a branch spec owned by you [-d implied]:
BranchSpec deleteBranchSpec = new BranchSpec();
deleteBranchSpec.Id = "newBranchSpec";
_repository.DeleteBranchSpec(deleteBranchSpec, null);
To delete a branch owned by someone other than you [-d implied] [-f requires admin privileges]:
BranchSpec deleteBranchSpec = new BranchSpec();
deleteBranchSpec.Id = "newBranchSpec";
Options opts = new Options(BranchSpecsCmdFlags.Force);
_repository.DeleteBranchSpec(deleteBranchSpec, opts);
Get client application information.
Information avout a connection's client-side application context.
p4 help info
info -- Display client/server information
p4 info [-s]
Info lists information about the current client (user name,
client name, applicable client root, client current directory,
and the client IP address) and some server information (server
IP address, server root, date, uptime, version and license data).
The -s option produces 'short' output that omits any information
that requires a database lookup such as the client root).
To get the current client host name:
ClientMetadata c = rep.GetClientMetadata();
string machinename = c.HostName;
Create a new job in the repository.
Job specification for the new job
The '-i' flags is needed when creating a new job
The Job object if new job was created, null if creation failed
The '-i' flags is added if not specified by the caller
p4 help job
job -- Create or edit a job (defect) specification
p4 job [-f] [jobName]
p4 job -d jobName
p4 job -o [jobName]
p4 job -i [-f]
The 'p4 job' command 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 associates changelists with jobs.
With no arguments, 'p4 job' creates an empty job specification
and invokes the user's editor. When the specification is saved,
a job name of the form jobNNNNNN is assigned. If the jobName
parameter is specified on the command line, the job is created or
opened for editing.
As jobs are entered or updated, all fields are indexed for searching
Text fields are broken into individual alphanumeric words (punctuation
and whitespace are ignored) and each word is case-folded and entered
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.
The fields that compose a job are defined by the 'p4 jobspec' command.
Perforce provides a default job specification that you can edit.
The -d flag deletes the specified job. You cannot delete a job if
it has pending or submitted fixes associated with it.
The -o flag writes the job specification to the standard output.
The user's editor is not invoked.
The -i flag reads a job specification from the standard input. The
user's editor is not invoked.
The -f flag enables you set fields that are read-only by default.
The -f flag requires 'admin' access, which is granted using the
'p4 protect' command.
To create a new job with a name 'Myjob':
Job job = new Job();
job.Id = "Myjob";
job.Add("Status", "open");
job.Add("User", "admin");
job.Add("Description", "this is a test job");
Job job = _repository.CreateJob( job, null);
To create a job with name of the form jobNNNNNN:
Job job = new Job();
job.Id = "new";
job.Add("Status", "open");
job.Add("User", "admin");
job.Add("Description", "this is a test job");
Job job = _repository.CreateJob( job, JobCmdFlags.Input);
Create a new job in the repository.
Job specification for the new job
The Job object if new job was created, null if creation failed
To create a new job name of the form jobNNNNNN:
Job job = new Job();
job.Id = new;
job.Add("Status", "open");
job.Add("User", "admin");
job.Add("Description", "this is a test job");
Job job = _repository.CreateJob( job );
Update the record for a job in the repository
Job specification for the job being updated
The Job object if new job was saved, null if creation failed
To update the description of job 'job000001':
Job job = _repository.GetJob("job000001");
job["Description"] += "\n\Updated description";
_repository.UpdateJob("job000001");
Get the record for an existing job from the repository.
Job name
There are no valid flags to use when fetching an existing job
The Job object if new job was found, null if the requested job does not exist
Get the record for job 'job000001':
Job job = _repository.GetJob("job000001", null);
Get the record for an existing job from the repository.
Job name
The Job object if new job was found, null if the requested job does not exist
Get the record for job 'job000001':
Job job = _repository.GetJob("job000001");
Get a list of jobs from the repository
options for the jobs command
A list containing the matching jobs
p4 help jobs
jobs -- Display list of jobs
p4 jobs [-e jobview -i -l -m max -r] [file[revRange] ...]
p4 jobs -R
Lists jobs in the server. If a file specification is included, fixes
for submitted changelists affecting the specified files are listed.
The file specification can include wildcards and a revision range.
See 'p4 help revisions' for details about specifying revisions.
The -e flag lists jobs matching the expression specified in the
jobview parameter. For a description of jobview syntax, see 'p4 help
jobview'.
The -i flag includes any fixes made by changelists integrated into
the specified files.
The -l flag produces long output with the full text of the job
descriptions.
The -m max flag limits the output to the first 'max' jobs, ordered
by their job name.
The -r flag sorts the jobs in reverse order (by job name).
The -R flag rebuilds the jobs table and reindexes each job, which
is necessary after upgrading to 98.2. 'p4 jobs -R' requires that
that the user be an operator or have 'super' access granted by
'p4 protect'.
To get a list of 100 jobs that include files under a given filepath:
FileSpec path = new FileSpec(new DepotPath(@"//depot/..."), null);
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.LongDescriptions, null, 100)), path);
To get a list of 100 jobs with the status "open":
string jobView = "status=open";
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.LongDescriptions, jobView, 100)), path);
To get a list of 10 jobs in reverse order:
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.ReverseSort, null, 10));
To get a list of 10 jobs that include any fixes made by changelists integrated into
the specified files:
FileSpec path = new FileSpec(new DepotPath(@"//depot/..."), null);
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.IncludeIntegratedFixes, null, 10)), path);
Delete a job from the repository
The job to be deleted
Only the '-f' flag is valid when deleting an existing job
To delete job000002 from the repository :
Job u = _repository.GetJob("job000002");
_repository.DeleteJob(u, null);
Create a new depot in the repository.
Depot specification for the new depot
The '-i' flag is required when creating a new depot
The Depot object if new depot was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d [-f] name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: 'local', 'stream', 'remote', 'spec', 'archive',
or 'unload'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
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
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
SpecMap: For spec depots, the optional description of which
specs should be saved, as one or more patterns.
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot. If any archive files remain in the depot directory, they may
be referenced by lazy copies in other depots; use 'p4 snap' to break
those linkages. Snap lazy copies prior to obliterating the old depot
files to allow the obliterate command to remove any unreferenced
archives from the depot directory. If the depot directory is not
empty, you must specify the -f flag to delete the depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
To create a streams depot named MobileApp:
Depot d = new Depot();
d.Id = "MobileApp";
d.Description = "Stream depot for mobile app project";
d.Owner = "admin";
d.Type = DepotType.Stream;
d.Map = "MobileApp/...";
Depot MobileApp = Repository.CreateDepot(d, null);
Create a new depot in the repository.
Depot specification for the new depot
The Depot object if new depot was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d [-f] name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: 'local', 'stream', 'remote', 'spec', 'archive',
or 'unload'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
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
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
SpecMap: For spec depots, the optional description of which
specs should be saved, as one or more patterns.
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot. If any archive files remain in the depot directory, they may
be referenced by lazy copies in other depots; use 'p4 snap' to break
those linkages. Snap lazy copies prior to obliterating the old depot
files to allow the obliterate command to remove any unreferenced
archives from the depot directory. If the depot directory is not
empty, you must specify the -f flag to delete the depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
To create a streams depot named MobileApp:
Depot d = new Depot();
d.Id = "MobileApp";
d.Description = "Stream depot for mobile app project";
d.Owner = "admin";
d.Type = DepotType.Stream;
d.Map = "MobileApp/...";
Depot MobileApp = Repository.CreateDepot(d);
Update the record for a depot in the repository
Depot specification for the depot being updated
The Depot object if new depot was saved, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d [-f] name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: 'local', 'stream', 'remote', 'spec', 'archive',
or 'unload'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
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
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
SpecMap: For spec depots, the optional description of which
specs should be saved, as one or more patterns.
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot. If any archive files remain in the depot directory, they may
be referenced by lazy copies in other depots; use 'p4 snap' to break
those linkages. Snap lazy copies prior to obliterating the old depot
files to allow the obliterate command to remove any unreferenced
archives from the depot directory. If the depot directory is not
empty, you must specify the -f flag to delete the depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
To update the streams depot named MobileApp:
Depot d = Repository.GetDepot("MobileApp");
// change description
d.Description = "Stream depot for Win8 phone apps";
Depot MobileApp = Repository.UpdateDepot(d);
Get the record for an existing depot from the repository.
Depot name
There are no valid flags to use when fetching an existing depot
The Depot object if depot was found, null if not
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d [-f] name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: 'local', 'stream', 'remote', 'spec', 'archive',
or 'unload'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
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
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
SpecMap: For spec depots, the optional description of which
specs should be saved, as one or more patterns.
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot. If any archive files remain in the depot directory, they may
be referenced by lazy copies in other depots; use 'p4 snap' to break
those linkages. Snap lazy copies prior to obliterating the old depot
files to allow the obliterate command to remove any unreferenced
archives from the depot directory. If the depot directory is not
empty, you must specify the -f flag to delete the depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
To get the spec for a streams depot named MobileApp:
Depot MobileApp = Repository.GetDepot("MobileApp", null);
Get the record for an existing depot from the repository.
Depot name
The Depot object if depot was found, null if not
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d [-f] name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: 'local', 'stream', 'remote', 'spec', 'archive',
or 'unload'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
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
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
SpecMap: For spec depots, the optional description of which
specs should be saved, as one or more patterns.
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot. If any archive files remain in the depot directory, they may
be referenced by lazy copies in other depots; use 'p4 snap' to break
those linkages. Snap lazy copies prior to obliterating the old depot
files to allow the obliterate command to remove any unreferenced
archives from the depot directory. If the depot directory is not
empty, you must specify the -f flag to delete the depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
To get the spec for a streams depot named MobileApp:
Depot MobileApp = Repository.GetDepot("MobileApp");
Get a list of depots from the repository
A list containing the matching depots
p4 help depots
depots -- Lists defined depots
p4 depots
Lists all depots defined in the server.
Depots takes no arguments.
To list the depots on the server:
IList<Depot> depots = Repository.GetDepots();
Delete a depot from the repository
The depot to be deleted
Only the '-d' flag is valid when deleting an existing depot
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d [-f] name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: 'local', 'stream', 'remote', 'spec', 'archive',
or 'unload'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
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
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
SpecMap: For spec depots, the optional description of which
specs should be saved, as one or more patterns.
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot. If any archive files remain in the depot directory, they may
be referenced by lazy copies in other depots; use 'p4 snap' to break
those linkages. Snap lazy copies prior to obliterating the old depot
files to allow the obliterate command to remove any unreferenced
archives from the depot directory. If the depot directory is not
empty, you must specify the -f flag to delete the depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
To delete a streams depot named MobileApp:
Depot d = Repository.GetDepot("MobileApp");
Repository.DeleteDepot(d, null);
Create a new group in the repository.
Group specification for the new group
The '-i' flags are required when creating a new group
The Group object if new group was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help group
group -- Change members of user group
p4 group [-a |-A] name
p4 group -d [-a] name
p4 group -o name
p4 group -i [-a]
Create a group or modify the membership of an existing group.
A group can contain users and other groups. The group specification
is put into a temporary file and the editor (configured by the
environment variable $P4EDITOR) is invoked.
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.
Each group has MaxResults, MaxScanRows, and MaxLockTime fields,
which limit the resources committed to operations performed by
members of the group. For these fields, 'unlimited' or 'unset'
means no limit for that group. An individual user's limit is the
highest of any group with a limit to which he belongs, unlimited if
any of his groups has 'unlimited' for that field, or unlimited
if he belongs to no group with a limit. See 'p4 help maxresults'
for more information on MaxResults, MaxScanRows and MaxLockTime.
Each group also has a Timeout field, which specifies how long (in
seconds) a 'p4 login' ticket remains valid. A value of 'unset' or
'unlimited' is equivalent to no timeout. An individual's timeout is
the highest of any group with a limit to which he belongs, unlimited
if any of his groups has 'unlimited' for the timeout value, or
unlimited if he belongs to no group with a limit. See 'p4 help login'
for more information.
Each group has a PasswordTimeout field, which determines how long a
password remains valid for members of the group.
The -d flag deletes a group.
The -o flag writes the group specification to standard output. The
user's editor is not invoked.
The -i flag reads a group specification from standard input. The
user's editor is not invoked. The new group specification replaces
the previous one.
The -a flag enables a user without 'super' access to modify the group
if that user is an 'owner' of that group. Group owners are specified
in the 'Owners' field of the group spec.
The -A flag enables a user with 'admin' access to add a new group.
Existing groups may not be modified when this flag is used.
All commands that require access granted by 'p4 protect' consider a
user's groups when calculating access levels.
'p4 group' requires 'super' access granted by 'p4 protect' unless
invoked with the '-a' flag by a qualified user.
To create the group 'Mygroup' with the owner 'Bob' and a user 'Ted'
when connected as super user:
string targetGroup = "Mygroup";
Group group = new Group();
group.Id = targetGroup;
group.UserNames = new List<string> { "Ted" };
group.OwnerNames = new List<string> { "Bob" };
_repository.CreateGroup(group, null);
To create a group "everyone" when connected as a user with admin level
rights:
string targetGroup = "everyone";
Group group = new Group();
group.Id = targetGroup;
group.UserNames = new List<string> { "Ted" };
group.OwnerNames = new List<string> { "Bob" };
_repository.CreateGroup(group, new Options(GroupCmdFlags.AdminAdd));
Create a new group in the repository.
Group specification for the new group
The Group object if new group was created, null if creation failed
To create the group 'Mygroup' with the owner 'Bob' and a users 'Ted' and 'Alex':
string targetGroup = "Mygroup";
Group group = new Group();
group.Id = targetGroup;
group.UserNames = new List<string> { "Ted", "Alex" };
group.OwnerNames = new List<string> { "Bob" };
_repository.CreateGroup(group);
Update the record for a group in the repository
Group specification for the group being updated
The Group object if new group was saved, null if creation failed
To add the user 'Carol' to the group 'Mygroup':
string targetGroup = "Mygroup";
Group group = GetGroup(targetGroup, null);
group.UserNames.Add("Carol");
_repository.UpdateGroup(group);
Update the record for a group in the repository
Group specification for the group being updated
The Group object if new group was saved, null if creation failed
To add the user 'Carol' to the group 'Mygroup':
string targetGroup = "Mygroup";
Group group = GetGroup(targetGroup, null);
group.UserNames.Add("Carol");
_repository.UpdateGroup(group);
Get the record for an existing group from the repository.
Group name
The Owner Access flag (-a) needs to be used if a user
without 'super' access is an 'owner' of that group.
The Group object if new group was found, null if creation failed
To get the group 'everyone' when connected as a user with super access:
string targetGroup = "everyone";
Group group = _repository.GetGroup(targetGroup, null);
To get the group 'Mygroup' when connected as a without super access
who is the owner of that group:
string targetGroup = "everyone";
GroupCmdOptions opts = new GroupCmdOptions(GroupCmdFlags.OwnerAccess);
Group group = _repository.GetGroup(targetGroup, opts);
Get the record for an existing group from the repository.
Group name
The Group object if new group was found, null if creation failed
To get the group 'everyone':
string targetGroup = "everyone";
IList<Group> group = _repository.getGroup(targetGroup);
Get a list of groups from the repository
options for the groups command
A list containing the matching groups
p4 help groups
groups -- List groups (of users)
p4 groups [-m max] [[[-i] user | group] | [-v [group]]]
List all user groups defined in the server. If a user argument is,
specified, only groups containing that user are displayed. If a group
argument is specified, only groups containing the group are displayed.
The -i flag also displays groups that the user or group belongs to
indirectly by means of membership in subgroups.
The -m max flag limits output to the specified number of groups.
The -v flag displays the MaxResults, MaxScanRows, MaxLockTime, and
Timeout values for the specified group.
To get the first 10 groups:
Options opts = new Options(GroupsCmdFlags.None, 10);
IList<Group> groups = _repository.getGroups(opts);
To get all groups that 'Bob' belongs to, including subgroups:
Options opts = new Options(GroupsCmdFlags.IncludeIndirect, -1);
IList<Group> groups = _repository.getGroups(opts, "Bob");
To get all the groups with the MaxResults, MaxScanRows, MaxLockTime, and
Timeout values for the specified group:
Options opts = new Options(GroupsCmdFlags.IncludeAllValues, -1);
IList<Group> groups = _repository.getGroups(opts);
Delete a group from the repository
The group to be deleted
The -a flag is needed to delete
a group when the user is an owner but not a superuser
To delete the group 'Mygroup' when the user is a superuser:
string targetGroup = "Mygroup";
Group group = new Group();
group.Id = targetGroup;
_repository.DeleteGroup(group, null);
To delete the group 'Mygroup' when the user is an owner but not a superuser:
string targetGroup = "Mygroup";
Group group = new _repository.GetGroup(targetGroup);
GroupCmdOptions opts = new GroupCmdOptions(GroupCmdFlags.OwnerAccess);
_repository.DeleteGroup(group, opts);
Create a new changelist in the repository.
Changelist specification for the new changelist
'-s', '-f', -u flags are valid when creating a new changelist
The Changelist object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To create a new changelist:
Changelist c = new Changelist();
c = Repository.CreateChangelist(c, null);
To create a new restricted changelist:
Changelist c = new Changelist();
c.Type = ChangeListType.Restricted;
c = Repository.CreateChangelist(c, null);
Create a new change in the repository.
Changelist specification for the new change
The Changelist object if new change was created, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To create a new changelist:
Changelist c = new Changelist();
c = Repository.CreateChangelist(c, null);
Update the record for a change in the repository
Changelist specification for the change being updated
The Changelist object if new change was saved, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To update changelist 15:
Changelist c = Repository.GetChangelist(15);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateChangelist(c);
Update the record for a change in the repository
Changelist specification for the change being updated
The Changelist object if new change was saved, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To update changelist 15:
Changelist c = Repository.GetChangelist(15);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateChangelist(c);
To update changelist 15 as an admin user, changing type to Public:
Changelist c = Repository.GetChangelist(15);
ChangeCmdOptions opts =
new ChangeCmdOptions(ChangeCmdFlags.Force);
c.Type = ChangeListType.Public;
c = Repository.UpdateChangelist(c, opts);
Update the record for a submitted change in the repository
Changelist specification for the change being updated
options for updating an existing change
The Changelist object if new change was saved, null if creation failed
Update the record for a change in the repository
Changelist specification for the change being updated
The Changelist object if new change was saved, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To update changelist 25:
Changelist c = Repository.GetChangelist(25);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateSubmittedChangelist(c);
Update the record for a submitted change in the repository
Changelist specification for the change being updated
options for the submitted change being updated
The Changelist object if new change was saved, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To update changelist 25:
Changelist c = Repository.GetChangelist(25);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateChangelist(c);
To update changelist 15 as an admin user, changing type to Public:
Changelist c = Repository.GetChangelist(25);
ChangeCmdOptions opts =
new ChangeCmdOptions(ChangeCmdFlags.Force);
c.Type = ChangeListType.Public;
c = Repository.UpdateChangelist(c, opts);
Get the record for an existing change from the repository.
Changelist name
'-f' or '-s' are valid flags to use when fetching an existing change
The Changelist object if new change was found, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To get changelist 25:
Changelist c = Repository.GetChangelist(25, null);
Get the record for an existing change from the repository.
Changelist name
'-f' or '-s' are valid flags to use when fetching an existing change
The Changelist object if new change was found, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To get changelist 25:
Changelist c = Repository.GetChangelist(25);
Get a list of changes from the repository
options for the changes command
array of FileSpecs for the changes command
A list containing the matching changes
p4 help changes
changes -- Display list of pending and submitted changelists
changelists -- synonym for 'changes'
p4 changes [options] [file[revRange] ...]
options: -i -t -l -L -f -c client -m max -s status -u user
Returns a list of all pending and submitted changelists currently
stored in the server.
If files are specified, 'p4 changes' lists only changelists that
affect those files. If the file specification includes a revision
range, 'p4 changes' lists only submitted changelists that affect
the specified revisions. See 'p4 help revisions' for details.
If files are not specified, 'p4 changes' limits its report
according to each change's type ('public' or 'restricted').
If a submitted or shelved change is restricted, the change is
not reported unless the user owns the change or has list
permission for at least one file in the change. Only the owner
of a restricted and pending (not shelved) change is permitted
to see it.
The -i flag also includes any changelists integrated into the
specified files.
The -t flag displays the time as well as the date.
The -l flag displays the full text of the changelist
descriptions.
The -L flag displays the changelist descriptions, truncated to 250
characters if longer.
The -f flag enables admin users to view restricted changes.
The -c client flag displays only submitted by the specified client.
The -m max flag limits changes to the 'max' most recent.
The -s status flag limits the output to pending, shelved or
submitted changelists.
The -u user flag displays only changes owned by the specified user.
To get all changelists owned by user bsmith:
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.None,
null, 0, ChangeListStatus.None, "bsmith");
IList<Changelist> changes =
Repository.GetChangelists(opts, null);
To get all shelved changelists in file path //depot/main/...:
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.None,
null, 0, ChangeListStatus.Shelved, null);
FileSpec file =
new FileSpec(new DepotPath("//depot/main/..."), null, null, null);
IList<Changelist> changes =
Repository.GetChangelists(opts, file);
To the 20 latest submitted changelists from client "build_workspace"
with their full description:
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.FullDescription,
"build_workspace", 20, ChangeListStatus.Submitted, null);
IList<Changelist> changes =
Repository.GetChangelists(opts, null);
To get all pending changelists as an admin user in file path
//depot/finance/... including restricted changelists:
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.ViewRestricted,
null, 0, ChangeListStatus.Pending, null);
FileSpec file =
new FileSpec(new DepotPath("//depot/finance/..."), null, null, null);
IList<Changelist> changes =
Repository.GetChangelists(opts, file);
Delete a change from the repository
The change to be deleted
The '-f' and '-s' flags are valid when deleting an existing change
Get the record for an existing change from the repository.
Changelist name
'-f' is a valid flag to use when deleting an existing change
The Changelist object if new change was found, null if creation failed
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [[-O] changelist#]
p4 change -d [-f -s -O] changelist#
p4 change -o [-s] [-f] [[-O] changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
p4 change -U user [-t restricted | public] [-f] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. Finally the -f flag can force changing the 'User' of
an empty pending change via -U. The -f flag requires 'admin'
access granted by 'p4 protect'. The -f and -u flags are mutually
exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -O flag specifies that the changelist number is the original
number of a changelist which was renamed on submit.
The -U flag changes the 'User' of an empty pending change to the
specified user. The user field can only be changed using this flag
by the user who created the change, or by a user with 'admin'
privilege using the -f flag. This option is useful for running
in a trigger or script.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
To delete pending changelist 34:
Repository.DeleteChangelist(34,null);
To delete pending changelist 34 as an admin user
who is not owner of the change:
ChangeCmdOptions opts = new ChangeCmdOptions(ChangeCmdFlags.Force);
Repository.DeleteChangelist(34, opts);
Create a new client in the repository.
Client specification for the new user
The '-i' flags is required when creating a new user
The Client object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [[-f] [-Fs]]name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
StreamAtChange:
Stream meta-data (for view creation) is versioned.
When StreamAtChange is set, the stream hierarchy is
constructed back-in-time to reproduce the view that was
available to clients in the past. With this field set
changes cannot be be submitted from the client.
StreamAtChange is optional; Stream must be set as well.
ServerID: If set, restricts usage to the named server.
If unset, usage is allowed on the master server and on
any replicas of the master other than Edge Servers.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete. The -Fs option used with -f
forces client deletion even when the user has shelved changes. In
this case, the shelved changes are left intact.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored. Using -S sets the client's
Stream field. The special syntax '-S //a/stream@changelist' can be
be used to set both Stream and StreamAtChange at the same time.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
A server of type 'build-server' (see 'p4 help server') is a replica
which supports build farm integration, and the 'p4 client' command
may be used to create or edit client workspaces on a build-server.
Such workspaces may issue the 'p4 sync' command, in addition to any
read-only command supported by the replica. For more information, run
'p4 help buildserver'.
When creating or editing a client workspace for a build-server,
the client specified by the optional 'name' argument, as well as the
client specified by the $P4CLIENT environment variable or via the
global '-c client' argument must not exist, or must be restricted
to this server; this command may not be used to create or edit a
workspace that is not restricted to this build-server.
To create a client named main_ws:
Client c = Repository.GetClient("main_ws");
c.OwnerName= "bsmith";
c.Description = "client for main dev";
Repository.CreateClient(c, null);
To create a client named main_ws using existing admin_main_ws
as a template:
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, "admin_main_ws", null, 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c, null);
To create a streams client named main_ws for the mainline stream
//MobileApp/Main:
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, null, "//MobileApp/Main", 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c, null);
Create a new client in the repository.
Client specification for the new user
The '-i' flags is required when creating a new user
The Client object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [[-f] [-Fs]]name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
StreamAtChange:
Stream meta-data (for view creation) is versioned.
When StreamAtChange is set, the stream hierarchy is
constructed back-in-time to reproduce the view that was
available to clients in the past. With this field set
changes cannot be be submitted from the client.
StreamAtChange is optional; Stream must be set as well.
ServerID: If set, restricts usage to the named server.
If unset, usage is allowed on the master server and on
any replicas of the master other than Edge Servers.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete. The -Fs option used with -f
forces client deletion even when the user has shelved changes. In
this case, the shelved changes are left intact.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored. Using -S sets the client's
Stream field. The special syntax '-S //a/stream@changelist' can be
be used to set both Stream and StreamAtChange at the same time.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
A server of type 'build-server' (see 'p4 help server') is a replica
which supports build farm integration, and the 'p4 client' command
may be used to create or edit client workspaces on a build-server.
Such workspaces may issue the 'p4 sync' command, in addition to any
read-only command supported by the replica. For more information, run
'p4 help buildserver'.
When creating or editing a client workspace for a build-server,
the client specified by the optional 'name' argument, as well as the
client specified by the $P4CLIENT environment variable or via the
global '-c client' argument must not exist, or must be restricted
to this server; this command may not be used to create or edit a
workspace that is not restricted to this build-server.
To create a client named main_ws:
Client c = Repository.GetClient("main_ws");
c.OwnerName= "bsmith";
c.Description = "client for main dev";
Repository.CreateClient(c);
To create a client named main_ws using existing admin_main_ws
as a template:
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, "admin_main_ws", null, 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c);
To create a streams client named main_ws for the mainline stream
//MobileApp/Main:
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, null, "//MobileApp/Main", 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c);
Update the record for a client in the repository
Client specification for the client being updated
The Client object if new client was saved, null if creation failed
Create a new client in the repository.
Client specification for the new user
The '-i' flags is required when creating a new user
The Client object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [[-f] [-Fs]]name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
StreamAtChange:
Stream meta-data (for view creation) is versioned.
When StreamAtChange is set, the stream hierarchy is
constructed back-in-time to reproduce the view that was
available to clients in the past. With this field set
changes cannot be be submitted from the client.
StreamAtChange is optional; Stream must be set as well.
ServerID: If set, restricts usage to the named server.
If unset, usage is allowed on the master server and on
any replicas of the master other than Edge Servers.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete. The -Fs option used with -f
forces client deletion even when the user has shelved changes. In
this case, the shelved changes are left intact.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored. Using -S sets the client's
Stream field. The special syntax '-S //a/stream@changelist' can be
be used to set both Stream and StreamAtChange at the same time.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
A server of type 'build-server' (see 'p4 help server') is a replica
which supports build farm integration, and the 'p4 client' command
may be used to create or edit client workspaces on a build-server.
Such workspaces may issue the 'p4 sync' command, in addition to any
read-only command supported by the replica. For more information, run
'p4 help buildserver'.
When creating or editing a client workspace for a build-server,
the client specified by the optional 'name' argument, as well as the
client specified by the $P4CLIENT environment variable or via the
global '-c client' argument must not exist, or must be restricted
to this server; this command may not be used to create or edit a
workspace that is not restricted to this build-server.
To update a client named main_ws:
Client c = Repository.GetClient("main_ws");
// change the description add add a MapEntry to the ViewMap
c.Description = "client for main dev. Adding tools path";
DepotPath left = new DepotPath("//depot/tools/...");
ClientPath right = new ClientPath("//main_ws/tools/...");
MapEntry line = new MapEntry(MapType.Include, left, right);
c.ViewMap.Add(line);
Repository.UpdateClient(c);
Get the record for an existing client from the repository.
Client name
There are no valid flags to use when fetching an existing client
The Client object if new client was found, null if creation failed
Create a new client in the repository.
Client specification for the new user
The '-i' flags is required when creating a new user
The Client object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [[-f] [-Fs]]name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
StreamAtChange:
Stream meta-data (for view creation) is versioned.
When StreamAtChange is set, the stream hierarchy is
constructed back-in-time to reproduce the view that was
available to clients in the past. With this field set
changes cannot be be submitted from the client.
StreamAtChange is optional; Stream must be set as well.
ServerID: If set, restricts usage to the named server.
If unset, usage is allowed on the master server and on
any replicas of the master other than Edge Servers.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete. The -Fs option used with -f
forces client deletion even when the user has shelved changes. In
this case, the shelved changes are left intact.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored. Using -S sets the client's
Stream field. The special syntax '-S //a/stream@changelist' can be
be used to set both Stream and StreamAtChange at the same time.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
A server of type 'build-server' (see 'p4 help server') is a replica
which supports build farm integration, and the 'p4 client' command
may be used to create or edit client workspaces on a build-server.
Such workspaces may issue the 'p4 sync' command, in addition to any
read-only command supported by the replica. For more information, run
'p4 help buildserver'.
When creating or editing a client workspace for a build-server,
the client specified by the optional 'name' argument, as well as the
client specified by the $P4CLIENT environment variable or via the
global '-c client' argument must not exist, or must be restricted
to this server; this command may not be used to create or edit a
workspace that is not restricted to this build-server.
To get the spec for a client named main_ws:
Client c = Repository.GetClient("main_ws", null);
Get the record for an existing client from the repository.
Client name
There are no valid flags to use when fetching an existing client
The Client object if new client was found, null if creation failed
Create a new client in the repository.
Client specification for the new user
The '-i' flags is required when creating a new user
The Client object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [[-f] [-Fs]]name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
StreamAtChange:
Stream meta-data (for view creation) is versioned.
When StreamAtChange is set, the stream hierarchy is
constructed back-in-time to reproduce the view that was
available to clients in the past. With this field set
changes cannot be be submitted from the client.
StreamAtChange is optional; Stream must be set as well.
ServerID: If set, restricts usage to the named server.
If unset, usage is allowed on the master server and on
any replicas of the master other than Edge Servers.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete. The -Fs option used with -f
forces client deletion even when the user has shelved changes. In
this case, the shelved changes are left intact.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored. Using -S sets the client's
Stream field. The special syntax '-S //a/stream@changelist' can be
be used to set both Stream and StreamAtChange at the same time.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
A server of type 'build-server' (see 'p4 help server') is a replica
which supports build farm integration, and the 'p4 client' command
may be used to create or edit client workspaces on a build-server.
Such workspaces may issue the 'p4 sync' command, in addition to any
read-only command supported by the replica. For more information, run
'p4 help buildserver'.
When creating or editing a client workspace for a build-server,
the client specified by the optional 'name' argument, as well as the
client specified by the $P4CLIENT environment variable or via the
global '-c client' argument must not exist, or must be restricted
to this server; this command may not be used to create or edit a
workspace that is not restricted to this build-server.
To get the spec for a client named main_ws:
Client c = Repository.GetClient("main_ws");
Get a list of clients from the repository
options for the clients command
A list containing the matching clients
p4 help clients
clients -- Display list of clients
workspaces -- synonym for 'clients'
p4 clients [-t] [-u user] [[-e|-E] nameFilter -m max] [-S stream]
[-a | -s serverID]
p4 clients -U
Lists all client workspaces currently defined in the server.
The -t flag displays the time as well as the date.
The -u user flag lists client workspaces that are owned by the
specified user.
The -e nameFilter flag lists workspaces with a name that matches
the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes
the matching case-insensitive.
The -m max flag limits output to the specified number of workspaces.
The -S stream flag limits output to the client workspaces dedicated
to the stream.
The -U flag lists unloaded clients (see 'p4 help unload').
The -a flag specifies that all clients should be displayed, not just
those that are bound to this server.
The -s serverID flag specifies that only those clients bound to the
specified serverID should be displayed. On an Edge Server, the -s
flag defaults to the Edge Server's serverID.
To get a list of a maximum of 10 clients:
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, null, null, 10, null));
IList<Client> clients = Repository.GetClients(opts);
To get a list of clients that have "iOS_app" in their name:
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, null, "*iOS_app*, 0, null));
IList<Client> clients = Repository.GetClients(opts);
To get a list of clients that can be used with stream //depot/main:
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, null, null, 0, "//depot/main"));
IList<Client> clients = Repository.GetClients(opts);
To get a list clients owned by user bsmith:
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, "bsmith", null, 0, null));
IList<Client> clients = Repository.GetClients(opts);
Delete a client from the repository
The client to be deleted
Only the '-f' flag is valid when deleting an existing client
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [[-f] [-Fs]]name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
StreamAtChange:
Stream meta-data (for view creation) is versioned.
When StreamAtChange is set, the stream hierarchy is
constructed back-in-time to reproduce the view that was
available to clients in the past. With this field set
changes cannot be be submitted from the client.
StreamAtChange is optional; Stream must be set as well.
ServerID: If set, restricts usage to the named server.
If unset, usage is allowed on the master server and on
any replicas of the master other than Edge Servers.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete. The -Fs option used with -f
forces client deletion even when the user has shelved changes. In
this case, the shelved changes are left intact.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored. Using -S sets the client's
Stream field. The special syntax '-S //a/stream@changelist' can be
be used to set both Stream and StreamAtChange at the same time.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
A server of type 'build-server' (see 'p4 help server') is a replica
which supports build farm integration, and the 'p4 client' command
may be used to create or edit client workspaces on a build-server.
Such workspaces may issue the 'p4 sync' command, in addition to any
read-only command supported by the replica. For more information, run
'p4 help buildserver'.
When creating or editing a client workspace for a build-server,
the client specified by the optional 'name' argument, as well as the
client specified by the $P4CLIENT environment variable or via the
global '-c client' argument must not exist, or must be restricted
to this server; this command may not be used to create or edit a
workspace that is not restricted to this build-server.
To delete a client named main_ws with the user who owns it:
Client c = Repository.GetClient("main_ws");
Repository.DeleteClient(c, null);
To delete a locked client named main_ws with an admin user:
Client c = Repository.GetClient("main_ws", null);
ClientCmdOptions opts = new ClientCmdOptions(ClientCmdFlags.Force);
rep.DeleteClient(c, opts);
Create a repository on the specified server.
The repository server.
Return a list of FileSpecs of files in the depot that correspond
to the passed-in FileSpecs.
p4 help files
files -- List files in the depot
p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
p4 files -U unloadfile ...
List details about specified files: depot file name, revision,
file, type, change action and changelist number of the current
head revision. If client syntax is used to specify the file
argument, the client view mapping is used to determine the
corresponding depot files.
By default, the head revision is listed. If the file argument
specifies a revision, then all files at that revision are listed.
If the file argument specifies a revision range, the highest revision
in the range is used for each file. For details about specifying
revisions, see 'p4 help revisions'.
The -a flag displays all revisions within the specific range, rather
than just the highest revision in the range.
The -A flag displays files in archive depots.
The -e flag displays files with an action of anything other than
deleted, purged or archived. Typically this revision is always
available to sync or integrate from.
The -m flag limits files to the first 'max' number of files.
The -U option displays files in the unload depot (see 'p4 help
unload' for more information about the unload depot).
To get a maximum of 10 files from the repository:
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.None, 10);
FileSpec fs = new FileSpec(new DepotPath("//depot/..."), null);
List<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
IList<FileSpec> files = Repository.GetDepotFiles(lfs, opts);
Return a list of Files opened by users / clients.
p4 help opened
opened -- List open files and display file status
p4 opened [-a -c changelist# -C client -u user -m max -s] [file ...]
p4 opened [-a -x -m max ] [file ...]
Lists files currently opened in pending changelists, or, for
specified files, show whether they are currently opened or locked.
If the file specification is omitted, all files open in the current
client workspace are listed.
Files in shelved changelists are not displayed by this command. To
display shelved changelists, see 'p4 changes -s shelved'; to display
the files in those shelved changelists, see 'p4 describe -s -S'.
The -a flag lists opened files in all clients. By default, only
files opened by the current client are listed.
The -c changelist# flag lists files opened in the specified
changelist#.
The -C client flag lists files open in the specified client workspace.
The -u user flag lists files opened by the specified user.
The -m max flag limits output to the first 'max' number of files.
The -s option produces 'short' and optimized output when used with
the -a (all clients) option. For large repositories '-a' can take
a long time when compared to '-as'.
The -x option lists files that are opened 'exclusive'. This option
only applies to a distributed installation where global tracking of
these file types is necessary across servers. The -x option implies
the -a option.
To get a maximum of 10 opened files from the repository, opened by
user fred, opened with any client:
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
List<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
// null for changelist and client options
GetOpenedFilesOptions opts =
new GetOpenedFilesOptions(GetOpenedFilesCmdFlags.AllClients,
null, null, "fred", 10);
IList<File> target = Repository.GetOpenedFiles(lfs, opts);
Use the p4 fstat command to get the file metadata for the files
matching the FileSpec.
p4 help fstat
fstat -- Dump file info
p4 fstat [-F filter -L -T fields -m max -r] [-c | -e changelist#]
[-Ox -Rx -Sx] file[rev] ...
Fstat lists information about files, one line per file. Fstat is
intended for use in Perforce API applications, where the output can
be accessed as variables, but its output is also suitable for parsing
from the client command output in scripts.
The fields that fstat displays are:
attr-<name> -- attribute value for <name>
attrProp-<name> -- set if attribute <name> is propagating
clientFile -- local path (host or Perforce syntax)
depotFile -- name in depot
movedFile -- name in depot of moved to/from file
path -- local path (host syntax)
isMapped -- set if mapped client file is synced
shelved -- set if file is shelved
headAction -- action at head rev, if in depot
headChange -- head rev changelist#, if in depot
headRev -- head rev #, if in depot
headType -- head rev type, if in depot
headCharset -- head charset, for unicode type
headTime -- head rev changelist time, if in depot
headModTime -- head rev mod time, if in depot
movedRev -- head rev # of moved file
haveRev -- rev had on client, if on client
desc -- change description
digest -- MD5 digest (fingerprint)
fileSize -- file size
action -- open action, if opened
type -- open type, if opened
charset -- open charset, for unicode type
actionOwner -- user who opened file, if opened
change -- open changelist#, if opened
resolved -- resolved integration records
unresolved -- unresolved integration records
reresolvable -- reresolvable integration records
otherOpen -- set if someone else has it open
otherOpen# -- list of user@client with file opened
otherLock -- set if someone else has it locked
otherLock# -- user@client with file locked
otherAction# -- open action, if opened by someone else
otherChange# -- changelist, if opened by someone else
openattr-<name> -- attribute value for <name>
openattrProp-<name> -- set if attribute <name> is propagating
ourLock -- set if this user/client has it locked
resolveAction# -- pending integration record action
resolveBaseFile# -- pending integration base file
resolveBaseRev# -- pending integration base rev
resolveFromFile# -- pending integration from file
resolveStartFromRev# -- pending integration from start rev
resolveEndFromRev# -- pending integration from end rev
totalFileCount -- total no. of files, if sorted
The -A <pattern> flag restricts displayed attributes to those
that match 'pattern'.
The -F flag lists only files satisfying the filter expression. This
filter syntax is similar to the one used for 'jobs -e jobview' and is
used to evaluate the contents of the fields in the preceding list.
Filtering is case-sensitive.
Example: -Ol -F "fileSize > 1000000 & headType=text"
Note: filtering is not optimized with indexes for performance.
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
The -T fields flag returns only the specified fields. The field names
can be specified using a comma- or space-delimited list.
Example: -Ol -T "depotFile, fileSize"
The -m max flag limits output to the specified number of files.
The -r flag sorts the output in reverse order.
The -c changelist# flag displays files modified after the specified
changelist was submitted. This operation is much faster than using
a revision range on the affected files.
The -e changelist# flag lists files modified by the specified
changelist. When used with the -Ro flag, only pending changes are
considered, to ensure that files opened for add are included. This
option also displays the change description.
The -O options modify the output as follows:
-Oa output attributes set by 'p4 attribute'.
-Od output the digest of the attribute.
-Oe output attribute values encoded as hex
-Of output all revisions for the given files (this
option suppresses other* and resolve* fields)
-Ol output a fileSize and digest field for each revision
(this may be expensive to compute)
-Op output the local file path in both Perforce syntax
(//client/) as 'clientFile' and host form as 'path'
-Or output pending integration record information for
files opened on the current client, or if used with
'-e <change> -Rs', on the shelved change
-Os exclude client-related data from output
The -R option limits output to specific files:
-Rc files mapped in the client view
-Rh files synced to the client workspace
-Rn files opened not at the head revision
-Ro files opened
-Rr files opened that have been resolved
-Rs files shelved (requires -e)
-Ru files opened that need resolving
The -S option changes the order of output:
-St sort by filetype
-Sd sort by date
-Sr sort by head revision
-Sh sort by have revision
-Ss sort by filesize
The -U flag displays information about unload files in the unload
depot (see 'p4 help unload').
For compatibility, the following flags are also supported:
-C (-Rc) -H (-Rh) -W (-Ro) -P (-Op) -l (-Ol) -s (-Os).
To get FileMetaData for //depot/ReadMe.txt:
FileSpec fs = new FileSpec(new DepotPath("//depot/MyCode/ReadMe.txt"), null);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None,
null, null, 0, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs);
To get FileMetaData for files in the depot that need resolving:
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.NeedsResolve,
null, null, 0, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs);
To get FileMetaData for files in the depot that are over a specific file
size and of file type, text:
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None,
"fileSize > 1000000 & headType=text", null, 0, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs);
To get FileMetaData for files in the depot that have been modified at or
after changelist 20345 and are mapped to the client view:
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.ClientMapped,
null, null, 20345, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs);
To get FileMetaData for files in the depot including attributes which match
the pattern "tested":
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.Attributes,
null, null, 0, null, null, "tested");
IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs);
Use the p4 fstat command to get the file metadata for the files
matching the FileSpec.
p4 help fstat
fstat -- Dump file info
p4 fstat [-F filter -L -T fields -m max -r] [-c | -e changelist#]
[-Ox -Rx -Sx] file[rev] ...
Fstat lists information about files, one line per file. Fstat is
intended for use in Perforce API applications, where the output can
be accessed as variables, but its output is also suitable for parsing
from the client command output in scripts.
The fields that fstat displays are:
attr-<name> -- attribute value for <name>
attrProp-<name> -- set if attribute <name> is propagating
clientFile -- local path (host or Perforce syntax)
depotFile -- name in depot
movedFile -- name in depot of moved to/from file
path -- local path (host syntax)
isMapped -- set if mapped client file is synced
shelved -- set if file is shelved
headAction -- action at head rev, if in depot
headChange -- head rev changelist#, if in depot
headRev -- head rev #, if in depot
headType -- head rev type, if in depot
headCharset -- head charset, for unicode type
headTime -- head rev changelist time, if in depot
headModTime -- head rev mod time, if in depot
movedRev -- head rev # of moved file
haveRev -- rev had on client, if on client
desc -- change description
digest -- MD5 digest (fingerprint)
fileSize -- file size
action -- open action, if opened
type -- open type, if opened
charset -- open charset, for unicode type
actionOwner -- user who opened file, if opened
change -- open changelist#, if opened
resolved -- resolved integration records
unresolved -- unresolved integration records
reresolvable -- reresolvable integration records
otherOpen -- set if someone else has it open
otherOpen# -- list of user@client with file opened
otherLock -- set if someone else has it locked
otherLock# -- user@client with file locked
otherAction# -- open action, if opened by someone else
otherChange# -- changelist, if opened by someone else
openattr-<name> -- attribute value for <name>
openattrProp-<name> -- set if attribute <name> is propagating
ourLock -- set if this user/client has it locked
resolveAction# -- pending integration record action
resolveBaseFile# -- pending integration base file
resolveBaseRev# -- pending integration base rev
resolveFromFile# -- pending integration from file
resolveStartFromRev# -- pending integration from start rev
resolveEndFromRev# -- pending integration from end rev
totalFileCount -- total no. of files, if sorted
The -A <pattern> flag restricts displayed attributes to those
that match 'pattern'.
The -F flag lists only files satisfying the filter expression. This
filter syntax is similar to the one used for 'jobs -e jobview' and is
used to evaluate the contents of the fields in the preceding list.
Filtering is case-sensitive.
Example: -Ol -F "fileSize > 1000000 & headType=text"
Note: filtering is not optimized with indexes for performance.
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
The -T fields flag returns only the specified fields. The field names
can be specified using a comma- or space-delimited list.
Example: -Ol -T "depotFile, fileSize"
The -m max flag limits output to the specified number of files.
The -r flag sorts the output in reverse order.
The -c changelist# flag displays files modified after the specified
changelist was submitted. This operation is much faster than using
a revision range on the affected files.
The -e changelist# flag lists files modified by the specified
changelist. When used with the -Ro flag, only pending changes are
considered, to ensure that files opened for add are included. This
option also displays the change description.
The -O options modify the output as follows:
-Oa output attributes set by 'p4 attribute'.
-Od output the digest of the attribute.
-Oe output attribute values encoded as hex
-Of output all revisions for the given files (this
option suppresses other* and resolve* fields)
-Ol output a fileSize and digest field for each revision
(this may be expensive to compute)
-Op output the local file path in both Perforce syntax
(//client/) as 'clientFile' and host form as 'path'
-Or output pending integration record information for
files opened on the current client, or if used with
'-e <change> -Rs', on the shelved change
-Os exclude client-related data from output
The -R option limits output to specific files:
-Rc files mapped in the client view
-Rh files synced to the client workspace
-Rn files opened not at the head revision
-Ro files opened
-Rr files opened that have been resolved
-Rs files shelved (requires -e)
-Ru files opened that need resolving
The -S option changes the order of output:
-St sort by filetype
-Sd sort by date
-Sr sort by head revision
-Sh sort by have revision
-Ss sort by filesize
The -U flag displays information about unload files in the unload
depot (see 'p4 help unload').
For compatibility, the following flags are also supported:
-C (-Rc) -H (-Rh) -W (-Ro) -P (-Op) -l (-Ol) -s (-Os).
To get FileMetaData for //depot/ReadMe.txt:
FileSpec fs = new FileSpec(new DepotPath("//depot/MyCode/ReadMe.txt"), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None,
null, null, 0, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts);
To get FileMetaData for files in the depot that need resolving:
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.NeedsResolve,
null, null, 0, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts);
To get FileMetaData for files in the depot that are over a specific file
size and of file type, text:
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None,
"fileSize > 1000000 & headType=text", null, 0, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts);
To get FileMetaData for files in the depot that have been modified at or
after changelist 20345 and are mapped to the client view:
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.ClientMapped,
null, null, 20345, null, null, null);
IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts);
To get FileMetaData for files in the depot including attributes which match
the pattern "tested":
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetFileMetaDataCmdOptions opts =
new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.Attributes,
null, null, 0, null, null, "tested");
IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts);
Return a list of Files in the depot that correspond to the passed-in
FileSpecs.
p4 help files
files -- List files in the depot
p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
p4 files -U unloadfile ...
List details about specified files: depot file name, revision,
file, type, change action and changelist number of the current
head revision. If client syntax is used to specify the file
argument, the client view mapping is used to determine the
corresponding depot files.
By default, the head revision is listed. If the file argument
specifies a revision, then all files at that revision are listed.
If the file argument specifies a revision range, the highest revision
in the range is used for each file. For details about specifying
revisions, see 'p4 help revisions'.
The -a flag displays all revisions within the specific range, rather
than just the highest revision in the range.
The -A flag displays files in archive depots.
The -e flag displays files with an action of anything other than
deleted, purged or archived. Typically this revision is always
available to sync or integrate from.
The -m flag limits files to the first 'max' number of files.
The -U option displays files in the unload depot (see 'p4 help unload'
for more information about the unload depot).
To get Files in local depot //depot/...:
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.None, 0);
FileSpec fs = new FileSpec(new DepotPath("//depot/..."), null);
IList<File> target = Repository.GetFiles(opts, fs);
To get Files in unload depot //Unloaded/...:
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.InUnloadDepot, 0);
FileSpec fs = new FileSpec(new DepotPath("//Unloaded/..."), null);
IList<File> target = Repository.GetFiles(opts, fs);
Return a list of Files in the depot that correspond to the passed-in
FileSpecs.
p4 help files
files -- List files in the depot
p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
p4 files -U unloadfile ...
List details about specified files: depot file name, revision,
file, type, change action and changelist number of the current
head revision. If client syntax is used to specify the file
argument, the client view mapping is used to determine the
corresponding depot files.
By default, the head revision is listed. If the file argument
specifies a revision, then all files at that revision are listed.
If the file argument specifies a revision range, the highest revision
in the range is used for each file. For details about specifying
revisions, see 'p4 help revisions'.
The -a flag displays all revisions within the specific range, rather
than just the highest revision in the range.
The -A flag displays files in archive depots.
The -e flag displays files with an action of anything other than
deleted, purged or archived. Typically this revision is always
available to sync or integrate from.
The -m flag limits files to the first 'max' number of files.
The -U option displays files in the unload depot (see 'p4 help unload'
for more information about the unload depot).
To get Files in local depot //depot/...:
FileSpec fs = new FileSpec(new DepotPath("//depot/..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.None, 0);
IList<File> target = Repository.GetFiles(lfs, opts);
To get Files in unload depot //Unloaded/...:
FileSpec fs = new FileSpec(new DepotPath("//Unloaded/..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.InUnloadDepot, 0);
IList<File> target = Repository.GetFiles(lfs, opts);
List selected directory paths in the repository.
p4 help dirs
dirs -- List depot subdirectories
p4 dirs [-C -D -H] [-S stream] dir[revRange] ...
List directories that match the specified file pattern (dir).
This command does not support the recursive wildcard (...).
Use the * wildcard instead.
Perforce does not track directories individually. A path is treated
as a directory if there are any undeleted files with that path as a
prefix.
By default, all directories containing files are listed. If the dir
argument includes a revision range, only directories containing files
in the range are listed. For details about specifying file revisions,
see 'p4 help revisions'.
The -C flag lists only directories that fall within the current
client view.
The -D flag includes directories containing only deleted files.
The -H flag lists directories containing files synced to the current
client workspace.
The -S flag limits output to depot directories mapped in a stream's
client view.
To get dirs on the server that fall within the current client view:
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.CurrentClientOnly, null);
IList<String> target = Repository.GetDepotDirs(opts, "//* );
To get dirs on the server that contain files synced to the current
client workspace:
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.SyncedDirs, null);
IList<String> target = Repository.GetDepotDirs(opts, "//* );
To get dirs on the server that fall under the path //depot/main/:
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.None, null);
IList<String> target = Repository.GetDepotDirs(opts, "//depot/main/* );
List selected directory paths in the repository.
p4 help dirs
dirs -- List depot subdirectories
p4 dirs [-C -D -H] [-S stream] dir[revRange] ...
List directories that match the specified file pattern (dir).
This command does not support the recursive wildcard (...).
Use the * wildcard instead.
Perforce does not track directories individually. A path is treated
as a directory if there are any undeleted files with that path as a
prefix.
By default, all directories containing files are listed. If the dir
argument includes a revision range, only directories containing files
in the range are listed. For details about specifying file revisions,
see 'p4 help revisions'.
The -C flag lists only directories that fall within the current
client view.
The -D flag includes directories containing only deleted files.
The -H flag lists directories containing files synced to the current
client workspace.
The -S flag limits output to depot directories mapped in a stream's
client view.
To get dirs on the server that fall within the current client view:
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.CurrentClientOnly, null);
IList<String> dirs = new List<String>()
dirs.Add("//*");
IList<String> target = Repository.GetDepotDirs(dirs, opts);
To get dirs on the server that contain files synced to the current
client workspace:
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.SyncedDirs, null);
IList<String> dirs = new List<String>()
dirs.Add("//*");
IList<String> target = Repository.GetDepotDirs(dirs, opts);
To get dirs on the server that fall under the path //depot/main/:
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.None, null);
IList<String> dirs = new List<String>()
dirs.Add("//depot/main/*");
IList<String> target = Repository.GetDepotDirs(dirs, opts);
Return the contents of the files identified by the passed-in file specs.
GetFileContents
p4 help print
print -- Write a depot file to standard output
p4 print [-a -o localFile -q] file[revRange] ...
Retrieve the contents of a depot file to the client's standard output.
The file is not synced. If file is specified using client syntax,
Perforce uses the client view to determine the corresponding depot
file.
By default, the head revision is printed. If the file argument
includes a revision, the specified revision is 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 printed. For details about revision specifiers, see 'p4
help revisions'.
The -a flag prints all revisions within the specified range, rather
than just the highest revision in the range.
The -o localFile flag redirects the output to the specified file on
the client filesystem.
The -q flag suppresses the initial line that displays the file name
and revision.
To get the contents of the file //depot/MyCode/README.txt:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
Return the contents of the files identified by the passed-in file specs.
GetFileContents
p4 help print
print -- Write a depot file to standard output
p4 print [-a -o localFile -q] file[revRange] ...
Retrieve the contents of a depot file to the client's standard output.
The file is not synced. If file is specified using client syntax,
Perforce uses the client view to determine the corresponding depot
file.
By default, the head revision is printed. If the file argument
includes a revision, the specified revision is 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 printed. For details about revision specifiers, see 'p4
help revisions'.
The -a flag prints all revisions within the specified range, rather
than just the highest revision in the range.
The -o localFile flag redirects the output to the specified file on
the client filesystem.
The -q flag suppresses the initial line that displays the file name
and revision.
To get the contents of the file //depot/MyCode/README.txt:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
Return the contents of the files identified by the passed-in file specs.
GetFileContentsEx
p4 help print
print -- Write a depot file to standard output
p4 print [-a -o localFile -q] file[revRange] ...
Retrieve the contents of a depot file to the client's standard output.
The file is not synced. If file is specified using client syntax,
Perforce uses the client view to determine the corresponding depot
file.
By default, the head revision is printed. If the file argument
includes a revision, the specified revision is 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 printed. For details about revision specifiers, see 'p4
help revisions'.
The -a flag prints all revisions within the specified range, rather
than just the highest revision in the range.
The -o localFile flag redirects the output to the specified file on
the client filesystem.
The -q flag suppresses the initial line that displays the file name
and revision.
To get the contents of the file //depot/MyCode/README.txt:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
Return the contents of the files identified by the passed-in file specs.
GetFileContentsEx
p4 help print
print -- Write a depot file to standard output
p4 print [-a -o localFile -q] file[revRange] ...
Retrieve the contents of a depot file to the client's standard output.
The file is not synced. If file is specified using client syntax,
Perforce uses the client view to determine the corresponding depot
file.
By default, the head revision is printed. If the file argument
includes a revision, the specified revision is 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 printed. For details about revision specifiers, see 'p4
help revisions'.
The -a flag prints all revisions within the specified range, rather
than just the highest revision in the range.
The -o localFile flag redirects the output to the specified file on
the client filesystem.
The -q flag suppresses the initial line that displays the file name
and revision.
To get the contents of the file //depot/MyCode/README.txt:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
Get the revision history data for the passed-in file specs.
p4 help filelog
filelog -- List revision history of files
p4 filelog [-c changelist# -h -i -l -L -t -m maxRevs -s] file[revRange] ...
List the revision history of the specified files, from the most
recent revision to the first. If the file specification includes
a revision, the command lists revisions at or prior to the specified
revision. If the file specification includes a revision range,
the command lists only the specified revisions. See 'p4 help revisions'
for details.
The -c changelist# flag displays files submitted at the specified
changelist number.
The -i flag includes inherited file history. If a file was created by
branching (using 'p4 integrate'), filelog lists the revisions of the
file's ancestors up to the branch points that led to the specified
revision. File history inherited by renaming (using 'p4 move') is
always displayed regardless of whether -i is specified.
The -h flag displays file content history instead of file name
history. The list includes revisions of other files that were
branched or copied (using 'p4 integrate' and 'p4 resolve -at') to
the specified revision. Revisions that were replaced by copying
or branching are omitted, even if they are part of the history of
the specified revision.
The -t flag displays the time as well as the date.
The -l flag lists the full text of the changelist descriptions.
The -L flag lists the full text of the changelist descriptions,
truncated to 250 characters if longer.
The -m maxRevs displays at most 'maxRevs' revisions per file of
the file[rev] argument specified.
The -s flag displays a shortened form of filelog that omits
non-contributory integrations.
To get the file history of the file //depot/MyCode/README.txt
submitted at change 43578 and showing the full changelist description:
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.FullDescription
43578, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileHistory(opts, filespec);
To get the file history of the file //depot/MyCode/README.txt
showing both time and date for the 10 latest revisions:
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.Time,
0, 10)
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileHistory(opts, filespec);
Get the revision history data for the passed-in file specs.
p4 help filelog
filelog -- List revision history of files
p4 filelog [-c changelist# -h -i -l -L -t -m maxRevs -s] file[revRange] ...
List the revision history of the specified files, from the most
recent revision to the first. If the file specification includes
a revision, the command lists revisions at or prior to the specified
revision. If the file specification includes a revision range,
the command lists only the specified revisions. See 'p4 help revisions'
for details.
The -c changelist# flag displays files submitted at the specified
changelist number.
The -i flag includes inherited file history. If a file was created by
branching (using 'p4 integrate'), filelog lists the revisions of the
file's ancestors up to the branch points that led to the specified
revision. File history inherited by renaming (using 'p4 move') is
always displayed regardless of whether -i is specified.
The -h flag displays file content history instead of file name
history. The list includes revisions of other files that were
branched or copied (using 'p4 integrate' and 'p4 resolve -at') to
the specified revision. Revisions that were replaced by copying
or branching are omitted, even if they are part of the history of
the specified revision.
The -t flag displays the time as well as the date.
The -l flag lists the full text of the changelist descriptions.
The -L flag lists the full text of the changelist descriptions,
truncated to 250 characters if longer.
The -m maxRevs displays at most 'maxRevs' revisions per file of
the file[rev] argument specified.
The -s flag displays a shortened form of filelog that omits
non-contributory integrations.
To get the file history of the file //depot/MyCode/README.txt
submitted at change 43578 and showing the full changelist description:
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.FullDescription
43578, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileHistory(filespecs, opts);
To get the file history of the file //depot/MyCode/README.txt
showing both time and date for the 10 latest revisions:
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.Time,
0, 10)
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileHistory(filespecs, opts);
Get content and existence diff details for two depot files.
p4 help diff2
diff2 -- Compare one set of depot files to another
p4 diff2 [options] fromFile[rev] toFile[rev]
p4 diff2 [options] -b branch [[fromFile[rev]] toFile[rev]]
p4 diff2 [options] -S stream [-P parent] [[fromFile[rev]] toFile[rev]]
options: -d<flags>> -Od -q -t -u
'p4 diff2' runs on the server to compare one set of depot files (the
'source') to another (the 'target'). Source and target file sets
can be specified on the 'p4 diff2' command line or through a branch
view.
With a branch view, fromFile and toFile are optional; fromFile limits
the scope of the source file set, and toFile limits the scope of the
target. If only one file argument is given, it is assumed to be
toFile.
fromFile and toFile can include revision specifiers; by default, the
head revisions are diffed. See 'p4 help revisions' for details
about specifying file revisions.
'p4 diff2' precedes each diffed file pair with a header line of the
following form:
==== source#rev (type) - target#rev (type) ==== summary
A source or target file shown as '<none>' means there is no file
at the specified name or revision to pair with its counterpart.
The summary status is one of the following: 'identical' means file
contents and types are identical, 'types' means file contents are
identical but the types are different, and 'content' means file
contents are different.
The -b flag makes 'p4 diff2' use a user-defined branch view. (See
'p4 help branch'.) The left side of the branch view is the source
and the right side is the target.
The -S flag makes 'p4 diff2' use a generated branch view that maps
a stream (or its underlying real stream) to its parent. -P can be
used to generate the branch view using a parent stream other than
the stream's actual parent.
The -d<flags> modify the output of diffs as follows:
-dn (RCS)
-dc[n] (context)
-ds (summary)
-du[n] (unified)
-db (ignore whitespace changes)
-dw (ignore whitespace)
-dl (ignore line endings).
The optional argument to -dc/-du specifies number of context lines.
The -Od flag limits output to files that differ.
The -q omits files that have identical content and types and
suppresses the actual diff for all files.
The -t flag forces 'p4 diff2' to diff binary files.
The -u flag uses the GNU diff -u format and displays only files
that differ. The file names and dates are in Perforce syntax, but
the output can be used by the patch program.
To get the depot file diffs between //depot/main/Program.cs and
//depot/rel/Program.cs and ignore whitespace changes:
GetDepotFileDiffsCmdOptions opts =
new GetDepotFileDiffsCmdOptions(GetDepotFileDiffsCmdFlags.IgnoreWhitespaceChanges,
0, 0, null,null,null);
IList<DepotFileDiff> target =
Repository.GetDepotFileDiffs(//depot/main/Program.cs,
//depot/rel/Program.cs, opts);
To get the depot files that differ between all files under //depot/main/... and
//depot/rel/... and display in GNU format only listing files that differ:
GetDepotFileDiffsCmdOptions opts =
new GetDepotFileDiffsCmdOptions(GetDepotFileDiffsCmdFlags.GNU,
0, 0, null,null,null);
IList<DepotFileDiff> target =
Repository.GetDepotFileDiffs(//depot/main/..., //depot/rel/..., opts);
Return FileAnnotation objects for the listed FileSpecs.
p4 help annotate
annotate -- Print file lines and their revisions
p4 annotate [-aciIq -d<flags>] file[revRange] ...
Prints all lines of the specified files, indicating the revision that
introduced each line into the file.
If the file argument includes a revision, then only revisions up to
the specified revision are displayed. If the file argument has a
revision range, only revisions within that range are displayed. For
details about specifying revisions, see 'p4 help revisions'.
The -a flag includes both deleted files and lines no longer present
at the head revision. In the latter case, both the starting and ending
revision for each line is displayed.
The -c flag directs the annotate command to output changelist numbers
rather than revision numbers for each line.
The -d<flags> change the way whitespace and/or line endings are
treated: -db (ignore whitespace changes), -dw (ignore whitespace),
-dl (ignore line endings).
The -i flag follows branches. If a file was created by branching,
'p4 annotate' includes the revisions of the source file up to the
branch point, just as 'p4 filelog -i' does. If a file has history
prior to being created by branching (such as a file that was branched
on top of a deleted file), -i ignores those prior revisions and
follows the source. -i implies -c.
The -I flag follows all integrations into the file. If a line was
introduced into the file by a merge, the source of the merge is
displayed as the changelist that introduced the line. If the source
itself was the result of an integration, that source is used instead,
and so on. -I implies -c.
The -q flag suppresses the one-line header that is displayed by
default for each file.
To get the file annotations of the file //depot/MyCode/README.txt:
GetFileAnnotationsCmdOptions opts =
new GetFileAnnotationsCmdOptions(GetFileAnnotationsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileAnnotation> target = Repository.GetFileAnnotations(filespecs, opts);
To get the file annotations of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the one-line header:
GetFileAnnotationsCmdOptions opts =
new GetFileAnnotationsCmdOptions(GetFileAnnotationsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileAnnotation> target = Repository.GetFileAnnotations(filespecs, opts);
Tag depot files with the passed-in label.
p4 help tag
tag -- Tag files with a label
p4 tag [-d -n] -l label file[revRange] ...
Tag associates the named label with the file revisions specified by
the file argument. After file revisions are tagged with a label,
revision specifications of the form '@label' can be used to refer
to them.
If the file argument does not include a revision specification, the
head revisions is tagged. See 'p4 help revisions' for revision
specification options.
If the file argument includes a revision range specification, only
the files with revisions in that range are tagged. Files with more
than one revision in the range are tagged at the highest revision.
The -d deletes the association between the specified files and the
label, regardless of revision.
The -n flag previews the results of the operation.
Tag can be used with an existing label (see 'p4 help labels') or
with a new one. An existing label can be used only by its owner,
and only if it is unlocked. (See 'p4 help label').
To list the file revisions tagged with a label, use 'p4 files
@label'.
To tag the file //depot/MyCode/README.txt with build_label:
TagCmdOptions opts =
new TagCmdOptions(TagFilesCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileSpec> target =
Repository.TagFiles(filespecs, "build_label", opts);
To remove the association between the file //depot/MyCode/README.txt
and build_label:
TagCmdOptions opts =
new TagCmdOptions(TagFilesCmdFlags.Delete, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileSpec> target =
Repository.TagFiles(filespecs, "build_label", opts);
To get a preview list of the files that would be tagged in path
//depot/main/src with build_label:
TagCmdOptions opts =
new TagCmdOptions(TagFilesCmdFlags.ListOnly, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/src/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileSpec> target =
Repository.TagFiles(filespecs, "build_label", opts);
List fixes affecting files and / or jobs and / or changelists.
p4 help fixes
fixes -- List jobs with fixes and the changelists that fix them
p4 fixes [-i -m max -c changelist# -j jobName] [file[revRange] ...]
'p4 fixes' list fixed jobs and the number of the changelist that
contains the fix.Fixes are associated with changelists using the
'p4 fix' command or by editing and submitting changelists.
The 'p4 fixes' command lists both submitted and pending changelists.
By default, 'p4 fixes' lists all fixes. This list can be limited
as follows: to list fixes for a specified job, use the -j jobName
flag. To list fixes for a specified changelist, use -c changelist#.
To list fixes that affect specified files, include the file argument.
The file pattern can include wildcards and revision specifiers. For
details about revision specifiers, see 'p4 help revisions'
The -i flag also includes any fixes made by changelists integrated
into the specified files.
The -m max flag limits output to the specified number of job
fixes.
To list the fixes related to job000001:
GetFixesCmdOptions opts =
new GetFixesCmdOptions(GetFixesCmdFlags.None, 0, "job000001", 0);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<Fix> target = Repository.GetFixes(filespecs, opts);
To list the fixes related to changelist 47921:
GetFixesCmdOptions opts =
new GetFixesCmdOptions(GetFixesCmdFlags.None, 47921, null, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<Fix> target = Repository.GetFixes(filespecs, opts);
To list the fixes related to path //depot/rel/src that occurred
between 2014/1/1 and 2014/1/31:
GetFixesCmdOptions opts =
new GetFixesCmdOptions(GetFixesCmdFlags.None, 0, null, 0);
VersionRange vr = new VersionRange(new DateTimeVersion(new DateTime(2014, 1, 1)),
new DateTimeVersion(new DateTime(2014, 1, 31)));
FileSpec filespec =
new FileSpec(new DepotPath("//..."), vr);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<Fix> target = Repository.GetFixes(filespecs, opts);
Get a list of matching lines in the passed-in file specs.
p4 help grep
grep -- Print lines matching a pattern
p4 grep [options] -e pattern file[revRange]...
options: -a -i -n -A <num> -B <num> -C <num> -t -s (-v|-l|-L) (-F|-G)
Searches files for lines that match the specified regular expression,
which can contain wildcards. The parser used by the Perforce server
is based on V8 regexp and might not be compatible with later parsers,
but the majority of functionality is available.
By default the head revision is searched. If the file argument includes
a revision specification, all corresponding revisions are searched.
If the file argument includes a revision range, only files in that
range are listed, and the highest revision in the range is searched.
For details about revision specifiers, see 'p4 help revisions'.
The -a flag searches all revisions within the specified range. By
default only the highest revision in the range is searched.
The -i flag causes the pattern matching to be case-insensitive. By
default, matching is case-sensitive.
The -n flag displays the matching line number after the file revision
number. By default, matches are displayed as revision#: <text>.
The -v flag displays files with non-matching lines.
The -F flag is used to interpret the pattern as a fixed string.
The -G flag is used to interpret the pattern as a regular expression,
which is the default behavior.
The -L flag displays the name of each selected file from which no
output would normally have been displayed. Scanning stops on the
first match.
The -l flag display the name of each selected file containing
matching text. Scanning stops on the first match.
The -s flag suppresses error messages that result from abandoning
files that have a maximum number of characters in a single line that
are greater than 4096. By default, an error is reported when grep
abandons such files.
The -t flag searches binary files. By default, only text files are
searched.
The -A <num> flag displays the specified number of lines of trailing
context after matching lines.
The -B <num> flag displays the specified number of lines of leading
context before matching lines.
The -C <num> flag displays the specified number of lines of output
context.
Regular expressions:
A regular expression is zero or more branches, separated by `|'. It
matches anything that matches one of the branches.
A branch is zero or more pieces, concatenated. It matches a match
for the first, followed by a match for the second, etc.
A piece is an atom possibly followed by `*', `+', or `?'. An atom
followed by `*' matches a sequence of 0 or more matches of the atom.
An atom followed by `+' matches a sequence of 1 or more matches of
the atom. An atom followed by `?' matches a match of the atom, or
the null string.
An atom is a regular expression in parentheses (matching a match for
the regular expression), a range (see below), `.' (matching any
single character), `^' (matching the null string at the beginning
of the input string), `$' (matching the null string at the end of
the input string), a `\' followed by a single character (matching
that character), or a single character with no other significance
(matching that character).
A range is a sequence of characters enclosed in `[]'. It normally
matches any single character from the sequence. If the sequence
begins with `^', it matches any single character not from the rest
of the sequence. If two characters in the sequence are separated by
`-', this is shorthand for the full list of ASCII characters between
them (e.g. `[0-9]' matches any decimal digit). To include a literal
`]' in the sequence, make it the first character (following a possible
`^'). To include a literal `-', make it the first or last character.
To get the file line matches for the pattern "OpenConnection" in the
file //depot/main/Program.cs with case-insensitive search:
GetFileLineMatchesCmdOptions opts =
new GetFileLineMatchesCmdOptions(GetFileLineMatchesCmdFlags.CaseInsensitive,
0, 0, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/Program.cs"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileLineMatch> target =
Repository.GetFileLineMatches(filespecs, "OpenConnection" opts);
To get the file line matches for the pattern "OpenConnection" in the
file //depot/main/Program.cs showing 2 lines before and after the found
pattern and showing line numbers:
GetFileLineMatchesCmdOptions opts =
new GetFileLineMatchesCmdOptions(GetFileLineMatchesCmdFlags.IncludeLineNumbers,
2, 2, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/Program.cs"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileLineMatch> target =
Repository.GetFileLineMatches(filespecs, "OpenConnection" opts);
Get a list of submitted integrations for the passed-in file specs.
p4 help integrated
integrated -- List integrations that have been submitted
p4 integrated [-r] [-b branch] [file ...]
The p4 integrated command lists integrations that have been submitted.
To list unresolved integrations, use 'p4 resolve -n'. To list
resolved but unsubmitted integrations, use 'p4 resolved'.
If the -b branch flag is specified, only files integrated from the
source to target files in the branch view are listed. Qualified
files are listed, even if they were integrated without using the
branch view.
The -r flag reverses the mappings in the branch view, swapping the
target files and source files. The -b branch flag is required.
To get the file intergration records for the path //depot/rel defined
by branch specification main_to_rel:
GetSubmittedIntegrationsCmdOptions opts =
new GetSubmittedIntegrationsCmdOptions(GetSubmittedIntegrationsCmdFlags.None,
"main_to_rel");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/rel/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileIntegrationRecord> target =
Repository.GetSubmittedIntegrations(filespecs, opts);
To get the file intergration records for the path //depot/main defined
by branch specification main_to_rel in reverse direction:
GetSubmittedIntegrationsCmdOptions opts =
new GetSubmittedIntegrationsCmdOptions(GetSubmittedIntegrationsCmdFlags.ReverseMappings,
"main_to_rel");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/rel/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileIntegrationRecord> target =
Repository.GetSubmittedIntegrations(filespecs, opts);
Get a list of Perforce protection entries for the passed-in file specs
p4 help protects
protects -- Display protections defined for a specified user and path
p4 protects [-a | -g group | -u user] [-h host] [-m] [file ...]
'p4 protects' displays the lines from the protections table that
apply to the current user. The protections table is managed using
the 'p4 protect' command.
If the -a flag is specified, protection lines for all users are
displayed. If the -g group flag or -u user flag is specified,
protection lines for that group or user are displayed.
If the -h host flag is specified, the protection lines that apply
to the specified host (IP address) are displayed.
If the -m flag is given, a single word summary of the maximum
access level is reported. Note that this summary does not take
exclusions into account.
If the file argument is specified, protection lines that apply to
the specified files are displayed.
The -a/-g/-u flags require 'super' access granted by 'p4 protect'.
To get the protections for the user tim for the entire server:
GetProtectionEntriesCmdOptions opts =
new GetProtectionEntriesCmdOptions(GetProtectionEntriesCmdFlags.None,
null, "tim", null);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
To get the protections summary for the group development tim for the entire server
when connecting from IP address 10.24.4.6:
GetProtectionEntriesCmdOptions opts =
new GetProtectionEntriesCmdOptions(GetProtectionEntriesCmdFlags.AccessSummary,
"development", null, "10.24.4.6");
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
List Perforce users assigned to review files.
p4 help reviews
reviews -- List the users who are subscribed to review files
p4 reviews [-c changelist#] [file ...]
'p4 reviews' lists all users who have subscribed to review the
specified files, the files in the specified changelist, or all files
(the default). To subscribe to review files, issue the 'p4 user'
command and edit the 'Reviews field'.
To get the list of users who are reviewing submits to //depot/main/src:
GetReviewersCmdOptions opts =
new GetReviewersCmdOptions(GetReviewersCmdFlags.None, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/src/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
To get the list of users who are reviewing submitted changelist 83476:
GetReviewersCmdOptions opts =
new GetReviewersCmdOptions(GetReviewersCmdFlags.None, 83476);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
Get a FormSpec of the specified form type.
p4 help spec
spec -- Edit spec definitions (unsupported)
p4 spec [-d -i -o] type
Edit any type of specification: branch, change, client, depot,
group, job, label, spec, stream, trigger, typemap, or user. Only
the comments and the formatting hints can be changed. Any fields
that you add during editing are discarded when the spec is saved.
'p4 jobspec' is equivalent to 'p4 spec job', and any custom spec
(include the job spec) can be deleted with 'p4 spec -d type'.
To get the FormSpec for changelist:
Options ops = new Options();
ops["-o"] = null;
FormSpec target = Repository.GetFormSpec(ops, "change");
To get the FormSpec for client:
Options ops = new Options();
ops["-o"] = null;
FormSpec target = Repository.GetFormSpec(ops, "clinet");
To get the FormSpec for user:
Options ops = new Options();
ops["-o"] = null;
FormSpec target = Repository.GetFormSpec(ops, "user");
Get the repository's trigger table.
p4 help triggers
triggers -- Modify list of server triggers
p4 triggers
p4 triggers -o
p4 triggers -i
'p4 triggers' edits the table of triggers, which are used for
change submission validation, form validation, external authentication,
external job fix integration, and external archive integration.
Triggers are administrator-defined commands that the server runs
to perform the following:
Validate changelist submissions.
The server runs changelist triggers before the file transfer,
between file transfer and changelist commit, or after the commit
Validate shelve operations.
The server runs shelve triggers before files are shelved, after
files are shelved, or when shelved files have been discarded
(via shelve -d).
Manipulate and validate forms.
The server runs form-validating triggers between generating
and outputting the form, between inputting and parsing the
form, between parsing and saving the form, or when deleting
the form.
Authenticate or change a user password.
The server runs authentication triggers to either validate
a user password during login or when setting a new password.
Intercept job fix additions or deletions.
The server run fix triggers prior to adding or deleting a fix
between a job and changelist.
Access external archive files.
For files with the +X filetype modifier, the server runs an
archive trigger to read, write, or delete files in the archive.
Command execution policy.
Command triggers can be specified to run before and after
processing of user requests. Pre-execution triggers can
prevent the command from running.
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 executed command exits returning 0 and fails otherwise.
Normally the failure of a trigger prevents the operation from
completing, except for the commit triggers, which run after the
operation is complete.
Each trigger line contains a trigger name, a trigger type, a depot
file path pattern or form type, and a command to run.
Name: The name of the trigger. For change triggers, a run of the
same trigger name on contiguous lines is treated as a single
trigger so that multiple paths can be specified. Only the
command of the first such trigger line is used.
Type: When the trigger is to execute:
archive:
Execute an archive trigger for the server to access
any file with the +X filetype modifier.
auth-check:
service-check:
Execute an authentication check trigger to verify a
user's password against an external password manager
during login or when setting a new password.
auth-check-sso:
Facilitate a single sign-on user authentication. This
configuration requires two programs or scripts to run;
one on the client, the other on the server.
client:
Set the environment variable 'P4LOGINSSO' to point to
a script that can be executed to obtain the user's
credentials or other information that the server
trigger can verify. The client-side script must
write the message to the standard output
(max length 128K).
Example: P4LOGINSSO=/Users/joe/bin/runsso
The 'server address' can be optionally passed to the
client script by appending %serverAddress% to the
client command string, as in:
P4LOGINSSO="/Users/joe/bin/runsso %serverAddress%"
server:
Execute an authentication (sso) trigger that gets
this message from the standard input and returns an
exit status of 0 (for verified) or otherwise failed.
Example:
sso auth-check-sso auth "/secure/verify %user%"
The user must issue the 'p4 login' command, but no
password prompting is invoked. If the server
determines that the user is valid, they are issued a
Perforce ticket just as if they had logged in with a
password.
Pre-2007.2 clients cannot run a client-side single
sign-on. Specifying an 'auth-check' trigger as a backup
for a user to gain access will prompt the user for a
password if it's an older client or P4LOGINSSO has not
been configured.
Unlike passwords which are encrypted, the sso message is
sent to the server in clear text.
auth-set:
Execute an authentication set trigger to send a new
password to an external password manager.
change-submit:
Execute pre-submit trigger after changelist has been
created and files locked but prior to file transfer.
change-content:
Execute mid-submit trigger after file transfer but prior
to commit. Files can be accessed by the 'p4 diff2',
'p4 files', 'p4 fstat', and 'p4 print' commands using
the revision specification '@=change', where 'change' is
the pending changelist number passed as %changelist%.
change-commit:
Execute post-submit trigger after changelist commit.
change-failed:
Executes only if the changelist commit failed.
Note that this trigger only fires on errors
occurring after a commit process has started. It does
not fire for early usage errors, or due to errors from
the submit form. In short, if an edge-* or change-*
trigger could have run, then the change-failed trigger
will fire if that commit fails.
command:
Execute pre/post trigger when users run commands.
edge-submit:
Execute pre-submit trigger on Edge Server after changelist
has been created but prior to file transfer.
edge-content:
Execute mid-submit trigger on Edge Server after file
transfer but prior to beginning submit on Commit Server.
fix-add:
Execute fix trigger prior to adding a fix. The special
variable %jobs% is available for expansion and must be
the last argument to the trigger as it expands to one
argument for each job listed on the 'p4 fix' command.
fix-delete:
Execute fix trigger prior to deleting a fix. The special
variable %jobs% is available for expansion and must be
the last argument to the trigger as it expands to one
argument for each job listed on the 'p4 fix -d' command.
form-out:
Execute form trigger on generation of form. Trigger may
modify form.
form-in:
Execute form trigger on input of form before its contents
are parsed and validated. Trigger may modify form.
form-save:
Execute form trigger prior to save of form after its
contents are parsed.
form-commit:
Execute form trigger after it has been committed, allowing
access to automatically generated fields (jobname, dates
etc). It cannot modify the form. This trigger for job
forms is run by 'p4 job' and 'p4 fix' (after the status
is updated), 'p4 change' (if the job is added or deleted)
and 'p4 submit' (if the job is associated with the change).
The 'form-commit' trigger has access to the new job name
created with 'p4 job', while the 'form-in' and 'form-save'
triggers are run before the job name is created. The
special variable %action% is available on the job
'form-commit' trigger command line, and is expanded when
the job is modified by a fix.
form-delete:
Execute form trigger prior to delete of form after its
contents are parsed.
shelve-submit:
Execute pre-shelve trigger after changelist has been
created but prior to file transfer.
shelve-commit:
Execute post-shelve trigger after files are shelved.
shelve-delete:
Execute shelve trigger prior to discarding shelved files.
Path: For change and submit triggers, a file pattern to match files
in the changelist. This file pattern can be an exclusion
mapping (-pattern), to exclude files. For form triggers, the
name of the form (branch, client, etc). For fix triggers
'fix' is required as the path value. For authentication
triggers, 'auth' is required as the path value. For archive
triggers, a file pattern to match the name of the file being
accessed in the archive. Note that, due to lazy copying when
branching files, the name of the file in the archive can not
be the same as the name of the file in the depot.
Command: The OS command to run for validation. If the command
contains spaces, enclose it in double quotes. The
following variables are expanded in the command string.
Use of the triggers.io configurable with a value greater than
zero is recommended, as some vars may be empty or contain
shell metacharacters.
%//depot/trigger.exe% -- depot paths within %vars%
are filled with the path to a temporary file containing
the referenced file's contents. Only standard and stream
depot files whose contents is available are valid.
%argc% -- number of command arguments
%args% -- command argument string
%client% -- the client issuing the command
%clientcwd% -- client current working directory
%clienthost% -- the hostname of the client
%clientip% -- the IP address of the client
%clientprog% -- the program name of the client
%clientversion% -- the version of the client
%command% -- name of command being run
%groups% -- list of groups user is a member of
%intermediateService% -- presence of a Broker/Proxy/etc
%maxErrorSeverity% -- highest error seen for this cmd
%maxErrorText% -- text and errno for highest error
%maxLockTime% -- user-specified override of group value
%maxResults% -- user-specified override of group value
%maxScanRows% -- user-specified override of group value
%quote% -- double quote character
%serverhost% -- the hostname of the server
%serverid% -- the value of the server's server.id
%serverip% -- the IP address of the server
%servername% -- the value of the server's $P4NAME
%serverpid% -- the PID of the server
%serverport% -- the IP address:port of the server
preceded by the transport prefix,
if needed (i.e. P4PORT)
%serverroot% -- the value of the server's $P4ROOT
%serverservices% -- the services provided by the server
%serverVersion% -- the server's version string
%terminated% -- if the command was forced to quit early
%termReason% -- reason for early termination
%triggerMeta_action% -- command to execute by trigger
%triggerMeta_depotFile% -- third field in trigger def.
%triggerMeta_name% -- name from trigger definition
%triggerMeta_trigger% -- second field in trigger definition
%user% -- the user issuing the command
%changelist% -- the changelist being submitted
%changeroot% -- the root path of files submitted
%oldchangelist% -- the pre-commit changelist number
(More information can be gathered about the
changelist being submitted by running
'p4 describe %changelist%'.)
%formfile% -- path to temp file containing form
%formname% -- the form's name (branch name, etc)
%formtype% -- the type of form (branch, etc)
%action% -- added/deleted/submitted on job form-commit
%jobs% -- list of job names for fix triggers
%op% -- read/write/delete for archive access
%file% -- name of archive file
%rev% -- revision of archive file
If the command was sent via a proxy, broker, or replica:
%peerhost% -- the hostname of the proxy/broker/replica
%peerip% -- the IP address of the proxy/broker/replica
If the command was sent directly, %peerhost% and
%peerip% match %clienthost% and %clientip%.
For a change-* trigger in a distributed installation,
%submitserverid% -- the server.id where submit was run
Note that not all variables are available for every
trigger type. E.g. argc and argv only show up for
pre-user-$cmd and change-submit (and so on), but not for
post-user-$cmd or change-commit.
The command's standard input depends on the value of the
triggers.io configurable. When it is set to zero, stdin is
empty for change, shelve, fix, command, and auth triggers, it
is the file content for the archive trigger. When triggers.io
is set to 1, (except for archive triggers,) stdin is a textual
dictionary containing connection information that the trigger.
must read.
If the command fails, the command's standard output (not
error output) is sent to the client as the text of a trigger
failure error message.
If the command succeeds, the command's standard output is
sent as an unadorned message to the client for all triggers
except archive triggers; for archive triggers, the command's
standard output is the file content.
The -o flag writes the trigger table to the standard output.
The user's editor is not invoked.
The -i flag reads the trigger table from the standard input.
The user's editor is not invoked.
'p4 triggers' requires 'super' access granted by 'p4 protect'.
To get the trigger table:
GetTriggerTableCmdOptions opts =
new GetTriggerTableCmdOptions(GetTriggerTableCmdFlags.Output);
IList<Trigger> target = Repository.GetTriggerTable(opts);
Get the repository's type map.
runs the command p4 typemap -o
p4 help typemap
typemap -- Edit the filename-to-filetype mapping table
p4 typemap
p4 typemap -o
p4 typemap -i
'p4 typemap' edits a name-to-type mapping table for 'p4 add', which
uses the table to assign a file's filetype based on its name.
The typemap form has a single field, 'TypeMap', followed by any
number of typemap lines. Each typemap line contains a filetype
and a depot file path pattern:
Filetype: See 'p4 help filetypes' for a list of valid filetypes.
Path: Names to be mapped to the filetype. The mapping is
a file pattern in depot syntax. When a user adds a file
matching this pattern, its default filetype is the
file type specified in the table. To exclude files from
the typemap, use exclusionary (-pattern) mappings.
To match all files anywhere in the depot hierarchy,
the pattern must begin with '//...'. To match files
with a specified suffix, use '//.../*.suffix' or
use '//....suffix' (four dots).
Later entries override earlier entries. If no matching entry is found
in the table, 'p4 add' determines the filetype by examining the file's
contents and execution permission bits.
The -o flag writes the typemap table to standard output. The user's
editor is not invoked.
The -i flag reads the typemap table from standard input. The user's
editor is not invoked.
'p4 typemap' requires 'admin' access, which is granted by 'p4 protect'.
To get the typemap table:
IList<TypeMapEntry> target = Repository.GetTypeMap();
Get the repository's protection table.
p4 help protect
protect -- Modify protections in the server namespace
p4 protect
p4 protect -o
p4 protect -i
'p4 protect' edits the protections table in a text form.
Each line in the table contains a protection mode, a group/user
indicator, the group/user name, client host ID and a depot file
path pattern. Users receive the highest privilege that is granted
on any line.
Note: remote depot are accessed using the pseudo-user 'remote'.
To control access from other servers that define your server as
a remote server, grant appropriate permissions to the 'remote' user.
Mode: The permission level or right being granted or denied.
Each permission level includes all the permissions above
it, except for 'review'. Each permission only includes
the specific right and no lesser rights. This approach
enables you to deny individual rights without having to
re-grant lesser rights. Modes prefixed by '=' are rights.
All other modes are permission levels.
Valid modes are:
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 open files (add, edit. delete,
integrate)
write - users can submit open files
admin - permits those administrative commands and
command options that don't affect the server's
security.
super - access to all commands and command options.
review - permits access to the 'p4 review' command;
implies read access
=read - if this right is denied, users can't sync,
diff, or print files
=branch - if this right is denied, users are not
permitted to use files as a source
for 'p4 integrate'
=open = if this right is denied, users cannot open
files (add, edit, delete, integrate)
=write = if this right is denied, users cannot submit
open files
Group/User indicator: specifies the grantee is a group or user.
Name: A Perforce group or user name; can include wildcards.
Host: The IP address of a client host; can include wildcards.
Path: The part of the depot to which access is being granted
or denied. To deny access to a depot path, preface the
path with a "-" character. These exclusionary mappings
apply to all access levels, even if only one access
level is specified in the first field.
The -o flag writes the protection table to the standard output.
The user's editor is not invoked.
The -i flag reads the protection table from the standard input.
The user's editor is not invoked.
After protections are defined, 'p4 protect' requires 'super'
access.
To get the protections table:
GetProtectionTableCmdOptions opts =
new GetProtectionTableCmdOptions(GetProtectionTableCmdFlags.Output);
IList<ProtectionEntry> target = Repository.GetProtectionTable(opts);
Get the Perforce counters for this repository.
p4 help counters
counters -- Display list of known counters
p4 counters [-e nameFilter -m max]
Lists the counters in use by the server. The server
uses the following counters directly:
change Current change number
job Current job number
journal Current journal number
lastCheckpointAction Data about the last complete checkpoint
logger Event log index used by 'p4 logger'
traits Internal trait lot number used by 'p4 attribute'
upgrade Server database upgrade level
The -e nameFilter flag lists counters with a name that matches
the nameFilter pattern, for example: -e 'mycounter-*'.
The -m max flag limits the output to the first 'max' counters.
The names 'minClient', 'minClientMessage', 'monitor',
'security', and 'unicode' are reserved names: do not use them
as ordinary counters.
For general-purpose server configuration, see 'p4 help configure'.
To get the counters on the server:
IList<Counter> target = Repository.GetCounters(null);
To get the counters on the server that start with the name "build_":
Options opts = new Options();
opts["-e"] = "build_*";
IList<Counter> target = Repository.GetCounters(opts);
Get a named Perforce counter value from the repository.
p4 help counter
counter -- Display, set, or delete a counter
p4 counter name
p4 counter [-f] name value
p4 counter [-f] -d name
p4 counter [-f] -i name
p4 counter [-f] -m [ pair list ]
The first form displays the value of the specified counter.
The second form sets the counter to the specified value.
The third form deletes the counter. This option usually has the
same effect as setting the counter to 0.
The -f flag sets or deletes counters used by Perforce, which are
listed by 'p4 help counters'. Important: Never set the 'change'
counter to a value that is lower than its current value.
The -i flag increments a counter by 1 and returns the new value.
This option is used instead of a value argument and can only be
used with numeric counters.
The fifth form allows multiple operations in one command.
With this, the list is pairs of arguments. Each pair is either
counter value or '-' counter. To set a counter use a name and value.
To delete a counter use a '-' followed by the name.
Counters can be assigned textual values as well as numeric ones,
despite the name 'counter'.
Counters can be assigned textual values as well as numeric ones,
despite the name 'counter'.
'p4 counter' requires 'review' access granted by 'p4 protect'.
The -f flag requires that the user be an operator or have 'super'
access.
To get the job counter:
Counter target = Repository.GetCounter("job", null);
To get the change counter:
Counter target = Repository.GetCounter("change", null);
To get the journal counter:
Counter target = Repository.GetCounter("journal", null);
Delete a Perforce counter from the repository.
p4 help counter
counter -- Display, set, or delete a counter
p4 counter name
p4 counter [-f] name value
p4 counter [-f] -d name
p4 counter [-f] -i name
p4 counter [-f] -m [ pair list ]
The first form displays the value of the specified counter.
The second form sets the counter to the specified value.
The third form deletes the counter. This option usually has the
same effect as setting the counter to 0.
The -f flag sets or deletes counters used by Perforce, which are
listed by 'p4 help counters'. Important: Never set the 'change'
counter to a value that is lower than its current value.
The -i flag increments a counter by 1 and returns the new value.
This option is used instead of a value argument and can only be
used with numeric counters.
The fifth form allows multiple operations in one command.
With this, the list is pairs of arguments. Each pair is either
counter value or '-' counter. To set a counter use a name and value.
To delete a counter use a '-' followed by the name.
Counters can be assigned textual values as well as numeric ones,
despite the name 'counter'.
'p4 counter' requires 'review' access granted by 'p4 protect'.
The -f flag requires that the user be an operator or have 'super'
access.
To delete a counter named test:
Counter target = Repository.DeleteCounter("test", null);
To delete a counter named build using -f with a user with
super access:
Options opts = new Options();
opts["-f"] = null;
Counter target = Repository.DeleteCounter("build", opts);
Create a new label in the repository.
Label specification for the new label
The '-i' flag is required when creating a new label
The Label object if new label was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help label
label -- Create or edit a label specification
p4 label [-f -g -t template] name
p4 label -d [-f -g] name
p4 label -o [-t template] name
p4 label -i [-f -g]
Create or edit a label. The name parameter is required. The
specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
The label specification form contains the following fields:
Label: The label name (read only.)
Owner: The user who created this label. Can be changed.
Update: The date that this specification was last modified.
Access: The date of the last 'labelsync' or use of '@label'
referencing this label.
Description: A short description of the label (optional).
Options: Flags to change the label behavior.
locked Prevents users other than the label owner
unlocked from changing the specification. Prevents
the label from being deleted. Prohibits
'p4 labelsync'. For a loaded label, prevents
'p4 unload'.
autoreload For a static label, indicates where label
noautoreload revisions are stored. Specify 'noautoreload'
to indicate that the revisions should be
stored in the db.label table. Specify
'autoreload' to indicate that the revisions
should be stored in the unload depot.
Revision: An optional revision specification for an automatic
label. Enclose in double quotes if it contains the
# (form comment) character. An automatic label can
be treated as a pure alias of a single revision
specification (excluding @label) provided that the
View mapping is empty.
View: A mapping that selects files from the depot. The
default view selects all depot files. Only the left
side of the mapping is used for labels. Leave this
field blank when creating an automatic label as
a pure alias.
ServerID: If set, restricts usage to the named server.
If unset, usage is allowed on any server.
A label is a named collection of revisions. A label is either
automatic or static. An automatic label refers to the revisions
given in the View: and Revision: fields. A static label refers to
the revisions that are associated with the label using the 'p4 tag'
or 'p4 labelsync' commands. A static label cannot have a Revison:
field. See 'p4 help revisions' for information on using labels as
revision specifiers.
Only the label owner can run 'p4 labelsync', and only if the label
is unlocked. A label without an owner can be labelsync'd by any user.
Flag -d deletes the specified label. You cannot delete a locked label.
The -f flag forces the delete.
The -o flag writes the label specification to standard output. The
user's editor is not invoked.
The -i flag reads a label specification from standard input. The
user's editor is not invoked.
The -t flag copies the view and options from the template label to
the new label.
The -f flag forces the deletion of a label. By default, locked labels
can only be deleted by their owner. The -f flag also permits the
Last Modified date to be set. The -f flag requires 'admin' access,
which is granted by 'p4 protect'.
The -g flag should be used on an Edge Server to update a global
label. Without -g, the label definition is visible only to users
of this Edge Server. Configuring rpl.labels.global=1 reverses this
default and causes this flag to have the opposite meaning.
To create a new label:
Label l = new Label();
l.Id = "newLabel";
l.Owner = "admin";
l.Description = "created by admin";
l.Options = "unlocked";
l.ViewMap = new ViewMap();
string v0 = "//depot/main/...";
string v1 = "//depot/rel1/...";
string v2 = "//depot/rel2/...";
string v3 = "//depot/dev/...";
l.ViewMap.Add(v0);
l.ViewMap.Add(v1);
l.ViewMap.Add(v2);
l.ViewMap.Add(v3);
Label newLabel = rep.CreateLabel(l, null);
To create a label using another label as a template:
Label newLabel2 = rep.CreateLabel(newLabel,
new LabelCmdOptions(LabelCmdFlags.None, newLabel.Id));
Create a new label in the repository.
Label specification for the new label
The Label object if new label was created, null if creation failed
To create a new label:
Label l = new Label();
l.Id = "newLabel";
l.Owner = "admin";
l.Description = "created by admin";
l.Options = "unlocked";
l.ViewMap = new ViewMap();
string v0 = "//depot/main/...";
string v1 = "//depot/rel1/...";
string v2 = "//depot/rel2/...";
string v3 = "//depot/dev/...";
l.ViewMap.Add(v0);
l.ViewMap.Add(v1);
l.ViewMap.Add(v2);
l.ViewMap.Add(v3);
Label newLabel = rep.CreateLabel(l, null);
Update the record for a label in the repository
Label specification for the label being updated
The Label object if new depot was saved, null if creation failed
To lock a label:
Label l = rep.GetLabel("admin_label");
l.Locked = true;
rep.UpdateLabel(l);
Get the record for an existing label from the repository.
Label name
Flags used when fetching an existing label
The Label object if label was found, null if creation failed
To get the admin_label with the gobal option:
LabelCmdOptions opts = new LabelCmdOptions(LabelCmdFlags.Global,null);
Label label = rep.GetLabel("admin_label", null, opts);
Get the record for an existing label from the repository.
Label name
The Label object if label was found, null if creation failed
To get the admin_label:
string targetLabel = "admin_label";
Label l = rep.GetLabel(targetLabel);
Get a list of labels from the repository
A list containing the matching labels
p4 help labels
p4 labels [-t] [-u user] [[-e|-E] nameFilter -m max] [file[revrange]]
p4 labels [-t] [-u user] [[-e|-E] nameFilter -m max] [-a|-s serverID]
p4 labels -U
Lists labels defined in the server.
If files are specified, 'p4 labels' lists the labels that contain
those files. If you include a file specification, automatic labels
and labels with the 'autoreload' option set are omitted from the list.
If the file specification includes a revision range, 'p4 labels'
lists labels that contain the specified revisions.
See 'p4 help revisions' for details about specifying revisions.
The -t flag displays the time as well as the date.
The -u user flag lists labels owned by the specified user.
The -e nameFilter flag lists labels with names that match the
the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes
the matching case-insensitive.
The -m max flag limits output to the first 'max' number of labels.
The -U flag lists unloaded labels (see 'p4 help unload').
The -a and -s flags are useful in a distributed server installation
(see 'p4 help distributed') in order to see the names of local labels
stored on other Edge Servers. These flags are not allowed if the
command includes a file specification.
The -a flag specifies that all labels should be displayed, not just
those that are bound to this server.
The -s serverID flag specifies that only those labels bound to the
specified serverID should be displayed.
On an Edge Server, if neither -s nor -a is specified, only those
local labels bound to this Edge Server are displayed. Labels created
on the Commit Server are global, and are also included in the output.
To get 50 labels on a distributed server installation:
LabelsCmdOptions opts = new LabelsCmdOptions(LabelsCmdFlags.All,
null, null, 50, null, null);
IList<Label> labels = rep.GetLabels(opts);
To get labels which contain files with the path //depot/Modifiers/...:
FileSpec path = new FileSpec(new DepotPath("//depot/Modifiers/..."), null);
Options ops = new Options();
IList<Label> l = rep.GetLabels(ops, path);
Delete a label from the repository
The label to be deleted
The 'f' and '-d' flags are valid when deleting an
existing label
To delete the label admin_label:
Label deleteTarget = new Label();
deleteTarget.Id = "admin_label";
rep.DeleteLabel(deleteTarget, null);
Create a new stream in the repository.
Stream specification for the new stream
The '-i' flag is required when creating a new stream
The Stream object if new stream was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help stream
stream -- Create, delete, or modify a stream specification
p4 stream [-P parent] -t type name
p4 stream [-f] [-d] [-o [-v]] [-P parent] -t type name
p4 stream -i [-f]
A stream specification ('spec') names a path in a stream depot to be
treated as a stream. (See 'p4 help streamintro'.) The spec also
defines the stream's lineage, its view, and its expected flow of
change.
The 'p4 stream' command puts the stream spec into a temporary file and
invokes the editor configured by the environment variable $P4EDITOR.
When creating a stream, the type of the stream must be specified with
the '-t' flag. Saving the file creates or modifies the stream spec.
Creating a stream spec does not branch a new stream. To branch a
stream, use 'p4 copy -r -S stream', where 'stream' is the name of a
stream spec.
The stream spec contains the following fields:
Stream: The stream's path in a stream depot, of the form
//depotname/streamname. This is both the name of the stream
spec and the permanent, unique identifier of the stream.
Update: The date this stream spec was last changed.
Access: The date of the last command used with this spec.
Owner: The stream's owner. Can be changed.
Name: An alternate name of the stream, for use in display outputs.
Defaults to the 'streamname' portion of the stream path.
Can be changed.
Parent: The parent of this stream. Can be 'none' if the stream type
is 'mainline', otherwise must be set to an existing stream
identfier, of the form //depotname/streamname.
Can be changed.
Type: 'mainline', 'virtual', 'development', 'release' or 'task'.
Defines the role of a stream: A 'mainline' may not have a
parent. A 'virtual' stream is not a stream but an alternate
view of its parent stream. The 'development' and 'release'
streams have controlled flow. Can be changed. A 'task'
stream is a lightweight short-lived stream that only
promotes edited files to the repository; branched and
integrated files are stored in shadow tables that are
removed when the task stream is deleted or unloaded.
Flow control is provided by 'p4 copy -S' and 'p4 merge -S'.
These commands restrict the flow of change as follows:
Stream Type Direction of flow Allowed with
----------- ----------------- ------------
development to parent stream 'p4 copy'
task to parent stream 'p4 copy'
release to parent stream 'p4 merge'
development from parent stream 'p4 merge'
release from parent stream 'p4 copy'
The [no]fromparent and [no]toparent options determine if
'p4 copy -S' and 'p4 merge -S' allow change to flow between
a stream and its parent. A 'virtual' stream must have its
flow options set as 'notoparent' and 'nofromparent'. Flow
options are ignored for 'mainline' streams.
Description: An optional description of the stream.
Options: Flags to configure stream behavior. Defaults are marked *:
unlocked * Indicates whether the stream spec is locked
locked against modifications. If locked, the spec
may not be deleted, and only its owner may
modify it.
allsubmit * Indicates whether all users or only the
ownersubmit of the stream may submit changes to the
stream path.
toparent * Indicates whether integration from the
notoparent stream to its parent is expected to occur.
fromparent * Indicates whether integration to the stream
nofromparent from its parent is expected to occur.
Paths: One or more lines that define file paths in the stream view.
Each line is of the form:
<path_type> <view_path> [<depot_path>]
where <path_type> is a single keyword, <view_path> is a file
path with no leading slashes, and the optional <depot_path>
is a file path beginning with '//'. Both <view_path> and
<depot_path> may contain trailing wildcards, but no leading
or embedded wildcards. Lines in the Paths field may appear
in any order. A duplicated <view_path> overrides its
preceding entry.
For example:
share src/...
import lib/abc/... //over/there/abc/...
isolate bin/*
Default is:
share ...
The <path_type> keyword must be one of:
share: <view_path> will be included in client views and
in branch views. Files in this path are accessible
to workspaces, can be submitted to the stream, and
can be integrated with the parent stream.
isolate: <view_path> will be included in client views but
not in branch views. Files in this path are
accessible to workspaces, can be submitted to the
stream, but are not integratable with the parent
stream.
import: <view_path> will be included in client views but
not in branch views. Files in this path are mapped
as in the parent stream's view (the default) or to
<depot_path> (optional); they are accessible to
workspaces, but can not be submitted or integrated
to the stream.
exclude: <view_path> will be excluded from client views
and branch views. Files in this path are not
accessible to workspaces, and can't be submitted
or integrated to the stream.
Paths are inherited by child stream views. A child stream's
paths can downgrade the inherited view, but not upgrade it.
(For instance, a child stream can downgrade a shared path to
an isolated path, but it can't upgrade an isolated path to a
shared path.) Note that <depot_path> is relevant only when
<path_type> is 'import'.
Remapped: Optional; one or more lines that define how stream view paths
are to be remapped in client views. Each line is of the form:
<view_path_1> <view_path_2>
where <view_path_1> and <view_path_2> are Perforce view paths
with no leading slashes and no leading or embedded wildcards.
For example:
... x/...
y/* y/z/*
Line ordering in the Remapped field is significant; if more
than one line remaps the same files, the later line has
precedence. Remapping is inherited by child stream client
views.
Ignored: Optional; a list of file or directory names to be ignored in
client views. For example:
/tmp # ignores files named 'tmp'
/tmp/... # ignores dirs named 'tmp'
.tmp # ignores file names ending in '.tmp'
Lines in the Ignored field may appear in any order. Ignored
names are inherited by child stream client views.
The -d flag causes the stream spec to be deleted. A stream spec may
not be deleted if it is referenced by child streams or stream clients.
Deleting a stream spec does not remove stream files, but it does mean
changes can no longer be submitted to the stream's path.
The -o flag causes the stream spec to be written to the standard
output. The user's editor is not invoked. -v may be used with -o to
expose the automatically generated client view for this stream.
('p4 help branch' describes how to expose the branch view.)
The -P flag can be used to insert a value into the Parent field of a
new stream spec. It has no effect on an existing spec.
The -t flag is used to insert a value into the type field of a
new stream spec and to adjust the default fromparent option
for a new 'release' -type stream. The flag has no effect on an
existing spec.
The -i flag causes a stream spec to be read from the standard input.
The user's editor is not invoked.
The -f flag allows a user other than the owner to modify or delete a
locked stream. It requires 'admin' access granted by 'p4 protect'.
To create a new mainline stream:
Stream main = new Stream();
string mainTargetId = "//Rocket/mainline";
main.Id = mainTargetId;
main.Type = StreamType.Mainline;
main.Parent = new DepotPath("none");
main.Options = new StreamOptionEnum(StreamOption.None);
main.Name = "mainline";
main.Paths = new ViewMap();
MapEntry p1 = new MapEntry(MapType.Import, new DepotPath("..."), null);
main.Paths.Add(p1);
MapEntry p2 = new MapEntry(MapType.Share, new DepotPath("core/gui/..."), null);
main.Paths.Add(p2);
main.OwnerName = "admin";
Stream mainline = rep.CreateStream(main, null);
To create a new development type stream with the parent //Rocket/mainline:
Stream dev = new Stream();
string developmentTargetId = "//Rocket/dev";
dev.Id = developmentTargetId;
dev.Type = StreamType.Development;
dev.Parent = new DepotPath("//Rocket/mainline");
dev.Name = "releasetest";
dev.Options = new StreamOptionEnum(StreamOption.None);
dev.Paths = new ViewMap();
MapEntry devp1 = new MapEntry(MapType.Share, new DepotPath("..."), null);
dev.Paths.Add(devp1);
dev.OwnerName = "admin";
Stream dev1 = rep.CreateStream(dev, null);
Create a new stream in the repository.
Stream specification for the new stream
The Stream object if new stream was created, null if creation failed
To create a new locked release type stream in the repository, with ignored and remapped
paths:
Stream s = new Stream();
string targetId = "//Rocket/rel1";
s.Id = targetId;
s.Type = StreamType.Release;
s.Options = new StreamOptionEnum(StreamOption.Locked | StreamOption.NoToParent);
s.Parent = new DepotPath("//Rocket/main");
s.Name = "Release1";
s.Paths = new ViewMap();
MapEntry p1 = new MapEntry(MapType.Import, new DepotPath("..."), null);
s.Paths.Add(p1);
MapEntry p2 = new MapEntry(MapType.Share, new DepotPath("core/gui/..."), null);
s.Paths.Add(p2);
s.OwnerName = "admin";
s.Description = "release stream for first release";
s.Ignored = new ViewMap();
MapEntry ig1 = new MapEntry(MapType.Include, new DepotPath(".tmp"), null);
s.Ignored.Add(ig1);
MapEntry ig2 = new MapEntry(MapType.Include, new DepotPath("/bmps/..."), null);
s.Ignored.Add(ig2);
MapEntry ig3 = new MapEntry(MapType.Include, new DepotPath("/test"), null);
s.Ignored.Add(ig3);
MapEntry ig4 = new MapEntry(MapType.Include, new DepotPath(".jpg"), null);
s.Ignored.Add(ig4);
s.Remapped = new ViewMap();
MapEntry re1 = new MapEntry(MapType.Include, new DepotPath("..."), new DepotPath("x/..."));
s.Remapped.Add(re1);
MapEntry re2 = new MapEntry(MapType.Include, new DepotPath("y/*"), new DepotPath("y/z/*"));
s.Remapped.Add(re2);
MapEntry re3 = new MapEntry(MapType.Include, new DepotPath("ab/..."), new DepotPath("a/..."));
s.Remapped.Add(re3);
Stream newStream = rep.CreateStream(s);
Update the record for a stream in the repository
Stream specification for the stream being updated
The Stream object if new stream was saved, null if creation failed
To set the locked option on a stream:
Stream streamToUpdate = rep.GetStream("//Rocket/GUI");
streamToUpdate.Options |= StreamOption.Locked;
streamToUpdate = rep.UpdateStream(streamToUpdate);
Update the record for a stream in the repository
Stream specification for the stream being updated
The Stream object if new stream was saved, null if creation failed
To update a locked stream when connected as an admin user:
Stream streamToUpdate = rep.GetStream("//Rocket/GUI");
// set locked option
streamToUpdate.Options |= StreamOption.Locked;
streamToUpdate = rep.UpdateStream(streamToUpdate);
streamToUpdate.Description = "edited";
string parent = streamToUpdate.Parent.ToString();
string type = streamToUpdate.Type.ToString();
streamToUpdate = rep.UpdateStream(streamToUpdate,
new StreamCmdOptions(StreamCmdFlags.Force, parent, type ));
Get the record for an existing stream from the repository.
Stream name
There are no valid flags to use when fetching an existing stream
The Stream object if new stream was found, null if creation failed
Get the stream with the stream Id "//Rocket/GUI":
string targetStream = "//Rocket/GUI";
Stream s = rep.GetStream(targetStream, null, null);
Get stream spec for a new development type stream with the parent
//Rocket/MAIN:
string targetStream = "//Rocket/GUI2";
string parentStream = "//Rocket/MAIN";
Stream stream = rep.GetStream(targetStream, parentStream,
new StreamCmdOptions(StreamCmdFlags.None, parentStream,
StreamType.Development.ToString()));
Get the record for an existing stream from the repository.
Stream name
The Stream object if new stream was found, null if creation failed
Get the stream with the stream Id "//Rocket/GUI":
string targetStream = "//Rocket/GUI";
Stream s = rep.GetStream(targetStream);
Delete a stream from the repository
The stream to be deleted
Only the '-f' flag is valid when deleting an existing stream
To delete a locked stream with no child streams or active clients as an admin user:
Stream stream = rep.GetStream("//Rocket/GUI");
StreamCmdOptions opts = new StreamCmdOptions(StreamCmdFlags.Force,
null, null);
rep.DeleteStream(stream, opts);
Get the integration status for a stream in the repository
The stream to get integration status on
options for the istat command
The integration status of the stream
p4 help istat
istat -- Show/cache a stream's integration status
p4 istat [ -a -c -r -s ] stream
'p4 istat' shows a stream's cached integration status with respect
to its parent. If the cache is stale, either because newer changes
have been submitted or the stream's branch view has changed, 'p4
istat' checks for pending integrations and updates the cache before
showing status.
Pending integrations are shown only if they are expected by the
stream; that is, only if they are warranted by the stream's type
and its fromParent/toParent flow options. (See 'p4 help stream'.)
The -r flag shows the status of integration to the stream from its
parent. By default, status of integration in the other direction is
shown, from the stream to its parent.
The -a flag shows status of integration in both directions.
The -c flag forces 'p4 istat' to assume the cache is stale; it
causes a search for pending integrations. Use of this flag can
impact server performance.
The -s flag shows cached state without refreshing stale data.
Get the direction of integration for stream "//Rocket/GUI" with respect
to its parent:
Stream s = rep.GetStream("//Rocket/GUI",null,null);
StreamMetaData smd = rep.GetStreamMetaData(s, null);
StreamMetaData.IntegAction action = smd.IntegToParentHow;
Get the direction of integration for stream "//Rocket/GUI" from its parent:
Stream s = rep.GetStream("//Rocket/GUI",null,null);
StreamMetaData smd = rep.GetStreamMetaData(s,new Options(GetStreamMetaDataCmdFlags.Reverse));
StreamMetaData.IntegAction action = smd.IntegFromParentHow;
Create a new user in the repository.
User specification for the new user
The '-f' and '-i' flags are required when creating a new user
The User object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
To create a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
User u = new User();
u.Id = "bsmith";
u.FullName = "Brian Smith";
u.EmailAddress = "bsmith@hotmail.com";
u = Repository.CreateUser(u, null);
To create a user with the username bsmith (when connected with
a user that has super access):
User u = new User();
u.Id = "bsmith";
u.FullName = "Brian Smith";
u.EmailAddress = "bsmith@hotmail.com";
UserCmdOptions opts = new UserCmdOptions(UserCmdFlags.Force);
u = Repository.CreateUser(u, opts);
Create a new user in the repository.
User specification for the new user
The User object if new user was created, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
To create a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
User u = new User();
u.Id = "bsmith";
u.FullName = "Brian Smith";
u.EmailAddress = "bsmith@hotmail.com";
u = Repository.CreateUser(u);
Update the record for a user in the repository
User specification for the user being updated
The User object if new user was saved, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
To update a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
User u = Repository.GetUser("bsmith");
// update email address
u.EmailAddress = "bsmith@hotmail.com";
u = Repository.UpdateUser(u, null);
Update the record for a user in the repository
User specification for the user being updated
The User object if new user was saved, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
To update a user with the username bsmith (when connected with
a user that has super access):
User u = Repository.GetUser("bsmith");
// update email address
u.EmailAddress = "bsmith@hotmail.com";
UserCmdOptions opts = new UserCmdOptions(UserCmdFlags.Force);
u = Repository.UpdateUser(u, opts);
Get the record for an existing user from the repository.
User name
There are no valid flags to use when fetching an existing user
The User object if new user was found, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
To get a user's specification for a user with the username bsmith:
User u = Repository.GetUser("bsmith", null);
Get the record for an existing user from the repository.
User name
There are no valid flags to use when fetching an existing user
The User object if new user was found, null if creation failed
The '-i' flag is added if not specified by the caller
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
To get a user's specification for a user with the username bsmith:
User u = Repository.GetUser("bsmith");
Get a list of users from the repository
Options for the users command. See:
Optional list of users.
A list containing the matching users
p4 help users
users -- List Perforce users
p4 users [-l -a -r -c] [-m max] [user ...]
Lists all Perforce users or users that match the 'user' argument.
The report includes the last time that each user accessed the system.
The -m max flag limits output to the first 'max' number of users.
The -a flag includes service and operator users in the output.
The -l flag includes additional information in the output. The -l
flag requires 'super' access, which is granted by 'p4 protect'.
The -r and -c flags are only allowed on replica servers. When
-r is given only users who have used a replica are reported and
when -c is given only the user information from the central server
is reported. Otherwise on a replica server, the user list will
be slightly different from the master server as the user access times
will reflect replica usage or master usage whichever is newer.
To get the first 10 users that start with the letter 'A':
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, 10);
IList<User> users = Repository.getUsers(opts, "A*");
To get the users for 'Bob', 'Ted', 'Carol' and 'Alice':
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, -1);
IList<User> users = Repository.getUsers(opts, "Bob", "Ted", "Carol", "Alice");
To get all the users (WARNING, will fetch all users from the repository):
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.IncludeAll, -1);
IList<User> users = Repository.getUsers(opts, null);
Get a list of users from the repository
Options for the users command. See:
Optional list of users.
A list containing the matching users
p4 help users
users -- List Perforce users
p4 users [-l -a -r -c] [-m max] [user ...]
Lists all Perforce users or users that match the 'user' argument.
The report includes the last time that each user accessed the system.
The -m max flag limits output to the first 'max' number of users.
The -a flag includes service and operator users in the output.
The -l flag includes additional information in the output. The -l
flag requires 'super' access, which is granted by 'p4 protect'.
The -r and -c flags are only allowed on replica servers. When
-r is given only users who have used a replica are reported and
when -c is given only the user information from the central server
is reported. Otherwise on a replica server, the user list will
be slightly different from the master server as the user access times
will reflect replica usage or master usage whichever is newer.
To get the first 10 users that start with the letter 'A':
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, 10);
IList<String> names = new List<String>();
names.Add("A*");
IList<User> users = Repository.getUsers(names, opts);
To get the users for 'Bob', 'Ted', 'Carol' and 'Alice':
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, -1);
IList<String> names = new List<String>();
names.Add("Bob");
names.Add("Ted");
names.Add("Carol");
names.Add("Alice");
IList<User> users = Repository.getUsers(names, opts);
To get all the users (WARNING, will fetch all users from the repository):
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.IncludeAll, -1);
IList<User> users = Repository.getUsers(null, opts);
Delete a user from the repository
The user to be deleted
Only the '-f' flag is valid when deleting an existing user
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
To delete a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
User u = Repository.GetUser("bsmith");
Repository.DeleteUser(u, null);
To delete a user with the username bsmith (when connected with
a user that has super access):
UserCmdOptions opts = new UserCmdOptions(UserCmdFlags.Force);
User u = Repository.GetUser("bsmith");
Repository.DeleteUser(u, opts);
Represents a specific Perforce server.
Represents the logical connection between a specific Perforce Server
instance and a specific client application.
Class representing the results of executing a command on a Perforce Server.
Create a P4CommandResult by running a command
Command to run
Flags for the command
Create a P4CommandResult by running a command
Command to run
Did the command not return any errors?
The info results (if any) of the command execution
The errors (if any) of the command execution
The text output from the command
The tagged output of the command
The binary output of the command
The command that was run
The arguments for command that was run
The time the command completed and the results were collected.
A branch view specification in a Perforce repository.
A branch view specification in a Perforce repository.
A branch view specification in a Perforce repository.
The date of the last command used with this spec.
A description of the branch spec (optional).
The branch spec name (read only).
When true, permits only the owner to change the spec.
Flags to change the branch spec behavior.
The user who created this branch spec.
Specifies structural and semantic metadata for form types.
The date this branch spec was last modified.
Lines mapping of one view of depot files to another.
Read the fields from the tagged output of a branch command
Tagged output from the 'branch' command
Parse the fields from a branch specification
Text of the branch specification in server format
Format of a branch specification used to save a branch to the server
Convert to specification in server format
Read the fields from the tagged output of a branches command
Tagged output from the 'branches' command
The branch spec name (read only).
The user who created this branch spec. Can be changed.
The date this branch spec was last modified.
The date of the last command used with this spec.
A description of the branch spec (optional).
When true, permits only the owner to change the spec.
Lines mapping of one view of depot files to another.
Specifies structural and semantic metadata for form types.
Flags to change the branch spec behavior.
Shelved file information from a Describe -S command
A changelist specification in a Perforce repository.
Create a new pending changelist
Create a new numbered changelist
Fill in the fields for the changelist using the tagged output of a "change' command
The tagged output of a "change' command
Fill in the fields for the changelist using the tagged output of a "change' command
The tagged output of a "change' command
Parse the fields from a changelist specification
Text of the changelist specification in server format
Format of a user specification used to save a user to the server
Convert to specification in server format
Convert to a string for display
Include the time as well as the date
p4 help fix
fix -- Mark jobs as being fixed by the specified changelist
p4 fix [-d] [-s status] -c changelist# jobName ...
'p4 fix' marks each named job as being fixed by the changelist
number specified with -c. The changelist can be pending or
submitted and the jobs can open or closed (fixed by another
changelist).
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 is closed when the
changelist is submitted. If the job is already closed, it remains
closed.
The -d flag deletes the specified fixes. This operation does not
otherwise affect the specified changelist or jobs.
The -s flag uses the specified status instead of the default defined
in the job specification. This status is reported by 'p4 fixes'.
The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit'
(of a pending changelist) commands set the job's status to the fix's
status for each job associated with the change. If the fix's status
is 'same', the job's status is left unchanged.
p4 help fix
fix -- Mark jobs as being fixed by the specified changelist
p4 fix [-d] [-s status] -c changelist# jobName ...
'p4 fix' marks each named job as being fixed by the changelist
number specified with -c. The changelist can be pending or
submitted and the jobs can open or closed (fixed by another
changelist).
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 is closed when the
changelist is submitted. If the job is already closed, it remains
closed.
The -d flag deletes the specified fixes. This operation does not
otherwise affect the specified changelist or jobs.
The -s flag uses the specified status instead of the default defined
in the job specification. This status is reported by 'p4 fixes'.
The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit'
(of a pending changelist) commands set the job's status to the fix's
status for each job associated with the change. If the fix's status
is 'same', the job's status is left unchanged.
Flags to configure the client behavior.
No options.
Leaves all files writable on the client;
by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option.
Permits 'p4 sync' to overwrite writable
files on the client. noclobber is ignored if
allwrite is set.
Compresses data sent between the client
and server to speed up slow connections.
Allows only the client owner to use or change
the client spec. Prevents the client spec from
being deleted.
Causes 'p4 sync' and 'p4 submit' to preserve
file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
Makes 'p4 sync' attempt to delete a workspace
directory when all files in it are removed.
Convert to a client spec formatted string
Parse a client spec formatted string
Flags to change submit behavior.
All open files are submitted (default).
Files that have content or type changes
are submitted. Unchanged files are
reverted.
Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
Client options that define what to do with files upon submit.
Convert to a client spec formatted string
Parse a client spec formatted string
Determines if the files is reopened upon submit.
Sets line-ending character(s) for client text files.
mode that is native to the client (default).
linefeed: UNIX style.
carriage return: Macintosh style.
carriage return-linefeed: Windows style.
hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
A client specification in a Perforce repository.
Parse the tagged output of a 'clients' command
Parse the tagged output of a 'client' command
Parse a client spec
Utility function to format a DateTime in the format expected in a spec
Format as a client spec
p4 help add
add -- Open a new file to add it to the depot
p4 add [-c changelist#] [-d -f -n] [-t filetype] file ...
Open a 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. To be added, the file must not
already reside in the depot, or it must be deleted at the current
head revision. Files can be deleted and re-added.
To associate the open files with a specific pending changelist, use
the -c flag; if you omit the -c flag, the open files are associated
with the default changelist. If file is already open, it is moved
into the specified pending changelist. You cannot reopen a file for
add unless it is already open for add.
As a shortcut to reverting and re-adding, you can use the -d
flag to reopen currently-open files for add (downgrade) under
the following circumstances:
A file that is 'opened for edit' and is synced to the head
revision, and the head revision has been deleted (or moved).
A file that is 'opened for move/add' can be downgraded to add,
which is useful when the source of the move has been deleted
or moved. Typically, under these circumstances, your only
alternative is to revert. In this case, breaking the move
connection enables you to preserve any content changes in the
new file and safely revert the source file (of the move).
To specify file type, use the -t flag. By default, 'p4 add'
determines file type using the name-to-type mapping table managed
by 'p4 typemap' and by examining the file's contents and execute
permission bit. If the file type specified by -t or configured in
the typemap table is a partial filetype, the resulting modifier is
applied to the file type that is determined by 'p4 add'. For more
details, see 'p4 help filetypes'.
To add files with filenames that contain wildcard characters, specify
the -f flag. Filenames that contain the special characters '@', '#',
'%' or '*' are reformatted to encode the characters using ASCII
hexadecimal representation. After the files are added, you must
refer to them using the reformatted file name, because Perforce
does not recognize the local filesystem name.
The -n flag displays a preview of the specified add operation without
changing any files or metadata.
p4 help delete
delete -- Open an existing file for deletion from the depot
p4 delete [-c changelist#] [-n -v -k] file ...
Opens a depot file for deletion.
If the file is synced in the client workspace, it is removed. If a
pending changelist number is specified using with the -c flag, the
file is opened for delete in that changelist. Otherwise, it is opened
in the default pending changelist.
Files that are deleted generally do not appear on the have list.
The -n flag displays a preview of the operation without changing any
files or metadata.
The -v flag enables you to delete files that are not synced to the
client workspace.
The -k flag performs the delete on the server without modifying
client files. Use with caution, as an incorrect delete can cause
discrepancies between the state of the client and the corresponding
server metadata.
p4 help edit
edit -- Open an existing file for edit
p4 edit [-c changelist#] [-k -n] [-t filetype] file ...
Open an existing file for edit. The server records the fact that
the current user has opened the file in the current workspace, and
changes the file permission from read-only to read/write.
If -c changelist# is included, the file opened in the specified
pending changelist. If changelist number is omitted, the file is
opened in the 'default' changelist.
If -t filetype is specified, the file is assigned that Perforce
filetype. Otherwise, the filetype of the previous revision is reused.
If a partial filetype is specified, it is combined with the current
filetype.For details, see 'p4 help filetypes'.
Using a filetype of 'auto' will cause the filetype to be choosen
as if the file were being added, that is the typemap will be
considered and the file contents may be examined.
The -n flag previews the operation without changing any files or
metadata.
The -k flag updates metadata without transferring files to the
workspace. This option can be used to tell the server that files in
a client workspace are already editable, even if they are not in the
client view. Typically this flag is used to correct the Perforce
server when it is wrong about the state of files in the client
workspace, but incorrect use of this option can result in inaccurate
file status information.
p4 help have
have -- List the revisions most recently synced to the current workspace
p4 have [file ...]
List revision numbers of the currently-synced files. If file name is
omitted, list all files synced to this client workspace.
The format is: depot-file#revision - client-file
p4 help integrate
integrate -- Integrate one set of files into another
p4 integrate [options] fromFile[revRange] toFile
p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
options: -c changelist# -d -f -h -i -o -n -m max -t -v
-D<flags> -R<flags>
'p4 integrate' integrates one set of files (the 'source') into
another (the 'target').
(See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
may be easier and more effective for the task at hand.)
Using the client workspace as a staging area, 'p4 integrate' adds and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits integrated files
to the depot. Unresolved files may not be submitted. Integrations
can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display integration history.
When 'p4 integrate' schedules a workspace file to be resolved, it
leaves it read-only. 'p4 resolve' can operate on a read-only file.
For other pre-submit changes, 'p4 edit' must be used to make the
file writable.
Source and target files can be specified either on the 'p4 integrate'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used on
toFile, it refers to source revisions, not to target revisions. For
details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 integrate' use a stream's branch view. (See
'p4 help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit integrated stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -b flag makes 'p4 integrate' use a user-defined branch view.
(See 'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Note that 'p4 integrate' automatically adusts source-to-target
mappings for moved and renamed files. (Adjustment occurs only if
the 'p4 move' command was used to move/rename files.) The scope of
source and target file sets must include both the old-named and the
new-named files for mappings to be adjusted. Moved source files may
cause target files to be scheduled for filename resolves.
The -f flag forces integrate to ignore integration history and treat
all source revisions as unintegrated. It is meant to be used with
revRange to force reintegration of specific, previously integrated
revisions.
The -i flag enables merging between files that have no prior
integration history. By default, 'p4 integrate' requires a prior
integration in order to identify a base for merging. The -i flag
allows the integration, and schedules the target file to be resolved
using the first source revision as the merge base.
The -o flag causes more merge information to be output. For each
target file scheduled to be resolved, the base file revision and the
source file revision are shown. (After running 'p4 integrate', the
same information is available from 'p4 resolve -o'.)
The -R flags modify the way resolves are scheduled:
-Rb Schedules 'branch resolves' instead of branching new
target files automatically.
-Rd Schedules 'delete resolves' instead of deleting
target files automatically.
-Rs Skips cherry-picked revisions already integrated.
This can improve merge results, but can also cause
multiple resolves per file to be scheduled.
The -D flags modify the way deleted files are treated:
-Dt If the target file has been deleted and the source
file has changed, re-branch the source file on top
of the target file instead of scheduling a resolve.
-Ds If the source file has been deleted and the target
file has changed, delete the target file instead of
scheduling a resolve.
-Di If the source file has been deleted and re-added,
probe revisions that precede the deletion to find
unintegrated revisions. By default, 'p4 integrate'
starts probing at the last re-added revision.
The -d flag is a shorthand for all -D flags used together.
The -h flag leaves the target files at the revision currently synced
to the client (the '#have' revision). By default, target files are
automatically synced to the head revision by 'p4 integrate'.
The -t flag propagates source filetypes instead of scheduling
filetype conflicts to be resolved.
The -m flag limits integration to the first 'max' number of files.
The -n flag displays a preview of integration, without actually
doing anything.
If -c changelist# is specified, the files are opened in the
designated numbered pending changelist instead of the 'default'
changelist.
The -v flag causes a 'virtual' integration that does not modify
client workspace files unless target files need to be resolved.
After submitting a virtual integration, 'p4 sync' can be used to
update the workspace.
p4 help integrate
integrate -- Integrate one set of files into another
p4 integrate [options] fromFile[revRange] toFile
p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
options: -c changelist# -d -f -h -i -o -n -m max -t -v
-D<flags> -R<flags>
'p4 integrate' integrates one set of files (the 'source') into
another (the 'target').
(See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
may be easier and more effective for the task at hand.)
Using the client workspace as a staging area, 'p4 integrate' adds and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits integrated files
to the depot. Unresolved files may not be submitted. Integrations
can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display integration history.
When 'p4 integrate' schedules a workspace file to be resolved, it
leaves it read-only. 'p4 resolve' can operate on a read-only file.
For other pre-submit changes, 'p4 edit' must be used to make the
file writable.
Source and target files can be specified either on the 'p4 integrate'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used on
toFile, it refers to source revisions, not to target revisions. For
details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 integrate' use a stream's branch view. (See
'p4 help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit integrated stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -b flag makes 'p4 integrate' use a user-defined branch view.
(See 'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Note that 'p4 integrate' automatically adusts source-to-target
mappings for moved and renamed files. (Adjustment occurs only if
the 'p4 move' command was used to move/rename files.) The scope of
source and target file sets must include both the old-named and the
new-named files for mappings to be adjusted. Moved source files may
cause target files to be scheduled for filename resolves.
The -f flag forces integrate to ignore integration history and treat
all source revisions as unintegrated. It is meant to be used with
revRange to force reintegration of specific, previously integrated
revisions.
The -i flag enables merging between files that have no prior
integration history. By default, 'p4 integrate' requires a prior
integration in order to identify a base for merging. The -i flag
allows the integration, and schedules the target file to be resolved
using the first source revision as the merge base.
The -o flag causes more merge information to be output. For each
target file scheduled to be resolved, the base file revision and the
source file revision are shown. (After running 'p4 integrate', the
same information is available from 'p4 resolve -o'.)
The -R flags modify the way resolves are scheduled:
-Rb Schedules 'branch resolves' instead of branching new
target files automatically.
-Rd Schedules 'delete resolves' instead of deleting
target files automatically.
-Rs Skips cherry-picked revisions already integrated.
This can improve merge results, but can also cause
multiple resolves per file to be scheduled.
The -D flags modify the way deleted files are treated:
-Dt If the target file has been deleted and the source
file has changed, re-branch the source file on top
of the target file instead of scheduling a resolve.
-Ds If the source file has been deleted and the target
file has changed, delete the target file instead of
scheduling a resolve.
-Di If the source file has been deleted and re-added,
probe revisions that precede the deletion to find
unintegrated revisions. By default, 'p4 integrate'
starts probing at the last re-added revision.
The -d flag is a shorthand for all -D flags used together.
The -h flag leaves the target files at the revision currently synced
to the client (the '#have' revision). By default, target files are
automatically synced to the head revision by 'p4 integrate'.
The -t flag propagates source filetypes instead of scheduling
filetype conflicts to be resolved.
The -m flag limits integration to the first 'max' number of files.
The -n flag displays a preview of integration, without actually
doing anything.
If -c changelist# is specified, the files are opened in the
designated numbered pending changelist instead of the 'default'
changelist.
The -v flag causes a 'virtual' integration that does not modify
client workspace files unless target files need to be resolved.
After submitting a virtual integration, 'p4 sync' can be used to
update the workspace.
p4 help integrate
integrate -- Integrate one set of files into another
p4 integrate [options] fromFile[revRange] toFile
p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
options: -c changelist# -d -f -h -i -o -n -m max -t -v
-D<flags> -R<flags>
'p4 integrate' integrates one set of files (the 'source') into
another (the 'target').
(See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
may be easier and more effective for the task at hand.)
Using the client workspace as a staging area, 'p4 integrate' adds and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits integrated files
to the depot. Unresolved files may not be submitted. Integrations
can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display integration history.
When 'p4 integrate' schedules a workspace file to be resolved, it
leaves it read-only. 'p4 resolve' can operate on a read-only file.
For other pre-submit changes, 'p4 edit' must be used to make the
file writable.
Source and target files can be specified either on the 'p4 integrate'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used on
toFile, it refers to source revisions, not to target revisions. For
details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 integrate' use a stream's branch view. (See
'p4 help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit integrated stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -b flag makes 'p4 integrate' use a user-defined branch view.
(See 'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Note that 'p4 integrate' automatically adusts source-to-target
mappings for moved and renamed files. (Adjustment occurs only if
the 'p4 move' command was used to move/rename files.) The scope of
source and target file sets must include both the old-named and the
new-named files for mappings to be adjusted. Moved source files may
cause target files to be scheduled for filename resolves.
The -f flag forces integrate to ignore integration history and treat
all source revisions as unintegrated. It is meant to be used with
revRange to force reintegration of specific, previously integrated
revisions.
The -i flag enables merging between files that have no prior
integration history. By default, 'p4 integrate' requires a prior
integration in order to identify a base for merging. The -i flag
allows the integration, and schedules the target file to be resolved
using the first source revision as the merge base.
The -o flag causes more merge information to be output. For each
target file scheduled to be resolved, the base file revision and the
source file revision are shown. (After running 'p4 integrate', the
same information is available from 'p4 resolve -o'.)
The -R flags modify the way resolves are scheduled:
-Rb Schedules 'branch resolves' instead of branching new
target files automatically.
-Rd Schedules 'delete resolves' instead of deleting
target files automatically.
-Rs Skips cherry-picked revisions already integrated.
This can improve merge results, but can also cause
multiple resolves per file to be scheduled.
The -D flags modify the way deleted files are treated:
-Dt If the target file has been deleted and the source
file has changed, re-branch the source file on top
of the target file instead of scheduling a resolve.
-Ds If the source file has been deleted and the target
file has changed, delete the target file instead of
scheduling a resolve.
-Di If the source file has been deleted and re-added,
probe revisions that precede the deletion to find
unintegrated revisions. By default, 'p4 integrate'
starts probing at the last re-added revision.
The -d flag is a shorthand for all -D flags used together.
The -h flag leaves the target files at the revision currently synced
to the client (the '#have' revision). By default, target files are
automatically synced to the head revision by 'p4 integrate'.
The -t flag propagates source filetypes instead of scheduling
filetype conflicts to be resolved.
The -m flag limits integration to the first 'max' number of files.
The -n flag displays a preview of integration, without actually
doing anything.
If -c changelist# is specified, the files are opened in the
designated numbered pending changelist instead of the 'default'
changelist.
The -v flag causes a 'virtual' integration that does not modify
client workspace files unless target files need to be resolved.
After submitting a virtual integration, 'p4 sync' can be used to
update the workspace.
p4 help labelsync
labelsync -- Apply the label to the contents of the client workspace
p4 labelsync [-a -d -n -q] -l label [file[revRange] ...]
Labelsync causes the specified label to reflect the current contents
of the client. It records the revision of each file currently synced.
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.
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 specified, labelsync updates the specified file.
If the file argument includes a revision specification, that revision
is used instead of the revision synced by the client. If the specified
revision is a deleted revision, the label includes that deleted
revision. See 'p4 help revisions' for details about specifying
revisions.
If the file argument includes a revision range specification,
only files selected by the revision range are updated, and the
highest revision in the range is used.
The -a flag adds the specified file to the label.
The -d deletes the specified file from the label, regardless of
revision.
The -n flag previews the operation without altering the label.
Only the owner of a label can run labelsync on that label. A label
that has its Options: field set to 'locked' cannot be updated.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are displayed.
p4 help labelsync
labelsync -- Apply the label to the contents of the client workspace
p4 labelsync [-a -d -n -q] -l label [file[revRange] ...]
Labelsync causes the specified label to reflect the current contents
of the client. It records the revision of each file currently synced.
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.
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 specified, labelsync updates the specified file.
If the file argument includes a revision specification, that revision
is used instead of the revision synced by the client. If the specified
revision is a deleted revision, the label includes that deleted
revision. See 'p4 help revisions' for details about specifying
revisions.
If the file argument includes a revision range specification,
only files selected by the revision range are updated, and the
highest revision in the range is used.
The -a flag adds the specified file to the label.
The -d deletes the specified file from the label, regardless of
revision.
The -n flag previews the operation without altering the label.
Only the owner of a label can run labelsync on that label. A label
that has its Options: field set to 'locked' cannot be updated.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are displayed.
p4 help lock
lock -- Lock an open file to prevent it from being submitted
p4 lock [-c changelist#] [file ...]
The specified files 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, the lock request
is rejected. If no file names are specified, all files in the
specified changelist are locked. If changelist number is omitted,
files in the default changelist are locked.
p4 help move
move -- move file(s) from one location to another
rename -- synonym for 'move'
p4 move [-c changelist#] [-f -n -k] [-t filetype] fromFile toFile
Move takes an already opened file and moves it from one client
location to another, reopening it as a pending depot move. When
the file is submitted with 'p4 submit', its depot file is moved
accordingly.
Wildcards in fromFile and toFile must match. The fromFile must be
a file open for add or edit.
'p4 opened' lists pending moves. 'p4 diff' can compare a moved
client file with its depot original, 'p4 sync' can schedule an
update of a moved file, and 'p4 resolve' can resolve the update.
A client file can be moved many times before it is submitted.
Moving a file back to its original location will undo a pending
move, leaving unsubmitted content intact. Using 'p4 revert'
undoes the move and reverts the unsubmitted content.
If -c changelist# is specified, the file is reopened in the
specified pending changelist as well as being moved.
The -f flag forces a move to an existing target file. The file
must be synced and not opened. The originating source file will
no longer be synced to the client.
If -t filetype is specified, the file is assigned that filetype.
If the filetype is a partial filetype, the partial filetype is
combined with the current filetype. See 'p4 help filetypes'.
The -n flag previews the operation without moving files.
The -k flag performs the rename on the server without modifying
client files. Use with caution, as an incorrect move can cause
discrepancies between the state of the client and the corresponding
server metadata.
The 'move' command requires a release 2009.1 or newer client. The
'-f' flag requires a 2010.1 client.
p4 help reopen
reopen -- Change the filetype of an open file or move it to
another changelist
p4 reopen [-c changelist#] [-t filetype] file ...
Reopen an open file for the current user in order to move it to a
different changelist or change its filetype.
The target changelist must exist; you cannot create a changelist by
reopening a file. To move a file to the default changelist, use
'p4 reopen -c default'.
If -t filetype is specified, the file is assigned that filetype. If
a partial filetype is specified, it is combined with the current
filetype. For details, see 'p4 help filetypes'.
Resolve files
The caller must either
1) set an automatic resolution (-as, -am.-af, -at, or -ay),
2) provide a callback function of type to
respond to the prompts, or 3) provide a dictionary which contains responses to the prompts.
p4 help resolve
resolve -- Resolve integrations and updates to workspace files
p4 resolve [options] [file ...]
options: -A<flags> -a<flags> -d<flags> -f -n -N -o -t -v
-c changelist#
'p4 resolve' resolves changes to files in the client workspace.
'p4 resolve' works only on files that have been scheduled to be
resolved. The commands that can schedule resolves are: 'p4 sync',
'p4 update', 'p4 submit', 'p4 merge', and 'p4 integrate'. Files must
be resolved before they can be submitted.
Resolving involves two sets of files, a source and a target. The
target is a set of depot files that maps to opened files in the
client workspace. When resolving an integration, the source is a
different set of depot files than the target. When resolving an
update, the source is the same set of depot files as the target,
at a different revision.
The 'p4 resolve' file argument specifies the target. If the file
argument is omitted, all unresolved files are resolved.
Resolving can modify workspace files. To back up files, use 'p4
shelve' before using 'p4 resolve'.
The resolve process is a classic three-way merge. The participating
files are referred to as follows:
'yours' The target file open in the client workspace
'theirs' The source file in the depot
'base' The common ancestor; the highest revision of the
source file already accounted for in the target.
'merged' The merged result.
Filenames, filetypes, and text file content can be resolved by
accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
binary file content can be resolved by accepting either 'yours' or
'theirs'.
When resolving integrated changes, 'p4 resolve' distinguishes among
four results: entirely yours, entirely theirs, a pure merge, or an
edited merge. The distinction is recorded when resolved files are
submitted, and will be used by future commands to determine whether
integration is needed.
In all cases, accepting 'yours' leaves the target file in its current
state. The result of accepting 'theirs' is as follows:
Content: The target file content is overwritten.
Branching: A new target is branched.
Deletion: The target file is deleted.
Filename: The target file is moved or renamed.
Filetype: The target file's type is changed.
For each unresolved change, the user is prompted to accept a result.
Content and non-content changes are resolved separately. For content,
'p4 resolve' places the merged result into a temporary file in the
client workspace. If there are any conflicts, the merged file contains
conflict markers that must be removed by the user.
'p4 resolve' displays a count of text diffs and conflicts, and offers
the following prompts:
Accept:
at Keep only changes to their file.
ay Keep only changes to your file.
* am Keep merged file.
* ae Keep merged and edited file.
* a Keep autoselected file.
Diff:
* dt See their changes alone.
* dy See your changes alone.
* dm See merged changes.
d Diff your file against merged file.
Edit:
et Edit their file (read only).
ey Edit your file (read/write).
* e Edit merged file (read/write).
Misc:
* m Run '$P4MERGE base theirs yours merged'.
(Runs '$P4MERGEUNICODE charset base theirs
yours merged' if set and the file is a
unicode file.)
s Skip this file.
h Print this help message.
^C Quit the resolve operation.
Options marked (*) appear only for text files. The suggested action
will be displayed in brackets.
The 'merge' (m) option enables you to invoke your own merge program, if
one is configured using the $P4MERGE environment variable. Four files
are passed to the program: the base, yours, theirs, and the temporary
file. The program is expected to write merge results to the temporary
file.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ab Resolve file branching.
-Ac Resolve file content changes.
-Ad Resolve file deletions.
-Am Resolve moved and renamed files.
-At Resolve filetype changes.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-as 'Safe' resolve; skip files that need merging.
-am Resolve by merging; skip files with conflicts.
-af Force acceptance of merged files with conflicts.
-at Force acceptance of theirs; overwrites yours.
-ay Force acceptance of yours; ignores theirs.
The -as flag causes the workspace file to be replaced with their file
only if theirs has changed and yours has not.
The -am flag causes the workspace file to be replaced with the result
of merging theirs with yours. If the merge detected conflicts, the
file is left untouched and uresolved.
The -af flag causes the workspace file to be replaced with the result
of merging theirs with yours, even if there were conflicts. This can
leave conflict markers in workspace files.
The -at flag resolves all files by copying theirs into yours. It
should be used with care, as it overwrites any changes made to the
file in the client workspace.
The -ay flag resolves all files by accepting yours and ignoring
theirs. It preserves the content of workspace files.
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-db Ingore whitespace changes.
-dw Ingore whitespace altogether.
-dl Ignores line endings.
The -d flags are also passed to the diff options in the 'p4 resolve'
dialog. Additional -d flags that modify the diff output but do not
modify merge behavior include -dn (RCS), -dc (context), -ds (summary),
and -du (unified). Note that 'p4 resolve' uses text from the client
file if the files differ only in whitespace.
The -f flag enables previously resolved content to be resolved again.
By default, after files have been resolved, 'p4 resolve' does not
process them again.
The -n flag previews the operation without altering files.
The -N flag previews the operation with additional information about
any non-content resolve actions that are scheduled.
The -o flag displays the base file name and revision to be used
during the the merge.
The -t flag forces 'p4 resolve' to attempt a textual merge, even for
files with non-text (binary) types.
The -v flag causes 'p4 resolve' to insert markers for all changes,
not just conflicts.
The -c flag limits 'p4 resolve' to the files in changelist#.
p4 help submit
submit -- Submit open files to the depot
p4 submit [-r -s -f option]
p4 submit [-r -s -f option] file
p4 submit [-r -f option] -d description
p4 submit [-r -f option] -d description file
p4 submit [-r -f option] -c changelist#
p4 submit -i [-r -s -f option]
'p4 submit' commits a pending changelist and its files to the depot.
By default, 'p4 submit' attempts to submit all files in the 'default'
changelist. Submit displays a dialog where you enter a description
of the change and, optionally, delete files from the list of files
to be checked in.
To add files to a changelist before submitting, use any of the
commands that open client workspace files: 'p4 add', 'p4 edit',
etc.
If the file parameter is specified, only files in the default
changelist that match the pattern are submitted.
Files in a stream path can be submitted only by client workspaces
dedicated to the stream. See 'p4 help client'.
Before committing a changelist, 'p4 submit' locks all the files being
submitted. If any file cannot be locked or submitted, the files are
left open in a numbered pending changelist. 'p4 opened' shows
unsubmitted files and their changelists.
Submit is atomic: if the operation succeeds, all files are updated
in the depot. If the submit fails, no depot files are updated.
The -c flag submits the specified pending changelist instead of the
default changelist. Additional changelists can be created manually,
using the 'p4 change' command, or automatically as the result of a
failed attempt to submit the default changelist.
The -d flag passes a description into the specified changelist rather
than displaying the changelist dialog for manual editing. This option
is useful for scripting, but does not allow you to add jobs or modify
the default changelist.
The -f flag enables you to override submit options that are configured
for the client that is submitting the changelist. This flag overrides
the -r (reopen)flag, if it is specified. See 'p4 help client' for
details about submit options.
The -i flag reads a changelist specification from the standard input.
The user's editor is not invoked.
The -r flag reopens submitted files in the default changelist after
submission.
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 details.
p4 help resolved
resolved -- Show files that have been resolved but not submitted
p4 resolved [-o] [file ...]
'p4 resolved' lists file updates and integrations that have been
resolved but not yet submitted. To see unresolved integrations,
use 'p4 resolve -n'. To see already submitted integrations, use
'p4 integrated'.
If a depot file path is specified, the output lists resolves for
'theirs' files that match the specified path. If a client file
path is specified, the output lists resolves for 'yours' files
that match the specified path.
The -o flag reports the revision used as the base during the
resolve.
RevertFilesOptions
p4 help revert
revert -- Discard changes from an opened file
p4 revert [-a -n -k -c changelist#] file ...
Revert an open file to the revision that was synced from the depot,
discarding any edits or integrations that have been made. You must
explicitly specify the files to be reverted. Files are removed from
the changelist in which they are open. Locked files are unlocked.
The -a flag reverts only files that are open for edit or integrate
and are unchanged or missing. Files with pending integration records
are left open. The file arguments are optional when -a is specified.
The -n flag displays a preview of the operation.
The -k flag marks the file as reverted in server metadata without
altering files in the client workspace.
The -c flag reverts files that are open in the specified changelist.
p4 help shelve
shelve -- Store files from a pending changelist into the depot
p4 shelve [files]
p4 shelve -i [-f | -r]
p4 shelve -r -c changelist#
p4 shelve -c changelist# [-f] [file ...]
p4 shelve -d -c changelist# [-f] [file ...]
'p4 shelve' creates, modifies or deletes shelved files in a pending
changelist. Shelved files remain in the depot until they are deleted
(using 'p4 shelve -d') or replaced by subsequent shelve commands.
After 'p4 shelve', the user can revert the files and restore them
later using 'p4 unshelve'. Other users can 'p4 unshelve' the stored
files into their own workspaces.
Files that have been shelved can be accessed by the 'p4 diff',
'p4 diff2', 'p4 files' and 'p4 print' commands using the revision
specification '@=change', where 'change' is the pending changelist
number.
By default, 'p4 shelve' creates a changelist, adds files from the
user's default changelist, then shelves those files in the depot.
The user is presented with a text changelist form displayed using
the editor configured using the $P4EDITOR environment variable.
If a file pattern is specified, 'p4 shelve' shelves the files that
match the pattern.
The -i flag reads the pending changelist specification with shelved
files from the standard input. The user's editor is not invoked.
To modify an existing changelist with shelved files, specify the
changelist number using the -c flag.
The -c flag specifies the pending changelist that contains shelved
files to be created, deleted, or modified. Only the user and client
of the pending changelist can add or modify its shelved files.
The -f (force) flag must be used with the -c or -i flag to overwrite
any existing shelved files in a pending changelist.
The -r flag (used with -c or -i) enables you to replace all shelved
files in that changelist with the files opened in your own workspace
at that changelist number. Only the user and client workspace of the
pending changelist can replace its shelved files.
The -d flag (used with -c) deletes the shelved files in the specified
changelist so that they can no longer be unshelved. By default, only
the user and client of the pending changelist can delete its shelved
files. A user with 'admin' access can delete shelved files by including
the -f flag to force the operation.
p4 help sync
sync -- Synchronize the client with its view of the depot
flush -- synonym for 'sync -k'
update -- synonym for 'sync -s'
p4 sync [-f -L -n -k -q] [-m max] [file[revRange] ...]
p4 sync [-L -n -q -s] [-m max] [file[revRange] ...]
p4 sync [-L -n -p -q] [-m max] [file[revRange] ...]
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 maps client and depot file names and
locations.
Sync adds files that are in the client view and have not been
retrieved before. Sync deletes previously retrieved files that
are no longer in the client view or have been deleted from the
depot. Sync updates files that are still in the client view and
have been updated in the depot.
By default, sync affects all files in the client workspace. If file
arguments are given, sync limits its operation to those files.
The file arguments can contain wildcards.
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.
If the file argument includes a revision range specification,
only files selected by the revision range are updated, and the
highest revision in the range is used.
Normally, sync does not overwrite workspace files that the user has
manually made writable. Setting the 'clobber' option in the
client specification disables this safety check.
The -f flag forces resynchronization even if the client already
has the file, and overwriting any writable files. This flag doesn't
affect open files.
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
The -n flag previews the operation without updating the workspace.
The -k flag updates server metadata without syncing files. It is
intended to enable you to ensure that the server correctly reflects
the state of files in the workspace while avoiding a large data
transfer. Caution: an erroneous update can cause the server to
incorrectly reflect the state of the workspace.
The -p flag populates the client workspace, but does not update the
server to reflect those updates. Any file that is already synced or
opened will be bypassed with a warning message. This option is very
useful for build clients or when publishing content without the
need to track the state of the client workspace.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are not suppressed.
The -s flag adds a safety check before sending content to the client
workspace. This check uses MD5 digests to compare the content on the
clients workspace against content that was last synced. If the file
has been modified outside of Perforce's control then an error message
is displayed and the file is not overwritten. This check adds some
extra processing which will affect the performance of the operation.
The -m flag limits sync to the first 'max' number of files. This
option is useful in conjunction with tagged output and the '-n'
flag, to preview how many files will be synced without transferring
all the file data.
p4 help unlock
unlock -- Release a locked file, leaving it open
p4 unlock [-c changelist#] [-f] [file ...]
'p4 unlock' releases locks on the specified files, which must be
open in the specified pending changelist. If you omit the changelist
number, the default changelist is assumed. If you omit the file name,
all locked files are unlocked.
By default, files can be unlocked only by the changelist owner. The
-f flag enables you to unlock files in changelists owned by other
users. The -f flag requires 'admin' access, which is granted by 'p4
protect'.
p4 help unshelve
unshelve -- Restore shelved files from a pending change into a workspace
p4 unshelve -s changelist# [-f -n] [-c changelist#] [file ...]
'p4 unshelve' retrieves shelved files from the specified pending
changelist, opens them in a pending changelist and copies them
to the invoking user's workspace. Unshelving files from a pending
changelist is restricted by the user's permissions on the files.
A successful unshelve operation places the shelved files on the
user's workspace with the same open action and pending integration
history as if it had originated from that user and client.
Unshelving a file over an already opened file is only permitted
if both shelved file and opened file are opened for 'edit'. After
unshelving, the workspace file is flagged as unresolved, and
'p4 resolve' must be run to resolve the differences between the
shelved file and the workspace file.
The -s flag specifies the number of the pending changelist that
contains the shelved files.
If a file pattern is specified, 'p4 unshelve' unshelves files that
match the pattern.
The -c flag specifies the changelist to which files are unshelved.
By default, 'p4 unshelve' opens shelved files in the default
changelist.
The -f flag forces the clobbering of any writeable but unopened files
that are being unshelved.
The -n flag previews the operation without changing any files or
metadata.
p4 help where
where -- Show how file names are mapped by the client view
p4 where [file ...]
Where shows how the specified files are mapped by 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.
If the file parameter is omitted, the mapping for all files in the
current directory and below) is returned.
Note that 'p4 where' does not determine where any real files reside.
It only displays the locations that are mapped by the client view.
p4 help copy
copy -- Copy one set of files to another
p4 copy [options] fromFile[rev] toFile
p4 copy [options] -b branch [-r] [toFile[rev] ...]
p4 copy [options] -b branch -s fromFile[rev] [toFile ...]
p4 copy [options] -S stream [-P parent] [-F] [-r] [toFile[rev] ...]
options: -c changelist# -n -v -m max
'p4 copy' copies one set of files (the 'source') into another (the
'target').
Using the client workspace as a staging area, 'p4 copy' makes the
target identical to the source by branching, replacing, or deleting
files. 'p4 submit' submits copied files to the depot. 'p4 revert'
can be used to revert copied files instead of submitting them. The
history of copied files can be shown with 'p4 filelog' or 'p4
integrated'.
Target files that are already identical to the source, or that are
outside of the client view, are not affected by 'p4 copy'. Opened,
non-identical target files cause 'p4 copy' to exit with a warning.
When 'p4 copy' creates or modifies files in the workspace, it leaves
them read-only; 'p4 edit' can make them writable. Files opened by
'p4 copy' do not need to be resolved.
Source and target files (fromFile and toFile) can be specified on
the 'p4 copy' command line or through a branch view. On the command
line, fromFile is the source file set and toFile is the target file
set. With a branch view, one or more toFile arguments can be given
to limit the scope of the target file set.
A revision specifier can be used to select the revision to copy; by
default, the head revision is copied. The revision specifier can be
used on fromFile, or on toFile, but not on both. When used on toFile,
it refers to source revisions, not to target revisions. A range may
not be used as a revision specifier. For revision syntax, see 'p4
help revisions'.
The -S flag makes 'p4 copy' use a stream's branch view. (See 'p4 help
stream'.) The source is the stream itself, and the target is the
stream's parent. With -r, the direction is reversed. -P can be used
to specify a parent stream other than the stream's actual parent.
Note that to submit copied stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -F flag can be used with -S to force copying even though the
stream does not expect a copy to occur in the direction indicated.
Normally 'p4 copy' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -b flag makes 'p4 copy' use a user-defined branch view. (See
'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the user-defined branch view to be
treated as the target, per the branch view mapping. Optional toFile
arguments may be given to further restrict the scope of the target
file set. -r is ignored when -s is used.
The -c changelist# flag opens files in the designated (numbered)
pending changelist instead of the default changelist.
The -n flag displays a preview of the copy, without actually doing
anything.
The -m flag limits the actions to the first 'max' number of files.
The -v flag causes a 'virtual' copy that does not modify client
workspace files. After submitting a virtual integration, 'p4 sync'
can be used to update the workspace.
p4 help merge
merge -- Merge one set of files into another
p4 merge [options] fromFile[revRange] toFile
p4 merge [options] -b branch [-r] [toFile[revRange] ...]
p4 merge [options] -b branch -s fromFile[revRange] [toFile ...]
p4 merge [options] -S stream [-P parent] [-F] [-r] [toFile[revRange] ...]
options: -c changelist# -n -m max
'p4 merge' merges changes from one set of files (the 'source') into
another (the 'target'). It is a simplified form of the 'p4 integrate'
command.
Using the client workspace as a staging area, 'p4 merge' branches and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits merged files to
the depot. Unresolved files may not be submitted. Merged files can
be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display merge history.
When 'p4 merge' schedules a workspace file to be resolved, it leaves
it read-only. 'p4 resolve' can operate on a read-only file; for
other pre-submit changes, 'p4 edit' must be used to make the file
writable.
Source and target files can be specified either on the 'p4 merge'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
Each file in the target is mapped to a file in the source. Mapping
adjusts automatically for files that have been moved or renamed, as
long as 'p4 move' was used to move/rename files. The scope of source
and target file sets must include both old-named and new-named files
for mappings to be adjusted. Moved source files may schedule moves
to be resolved in target files.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used
on toFile, it refers to source revisions, not to target revisions.
For details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 merge' use a stream's branch view. (See 'p4
help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit merged stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -F flag can be used with -S to force merging even though the
stream does not expect a merge to occur in the direction indicated.
Normally 'p4 merge' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -b flag makes 'p4 merge' use a user-defined branch view. (See
'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Metadata from the client associated with a connection.
Read the fields from the tagged output of an info command
Tagged output from the 'info' command
Flags for the server connection status.
Disconnected from server.
Connected to server.
Represents the logical connection between a specific Perforce
Server instance and a specific client application.
Release the connection held by the bridge to the server. This will cause the
bridge to call init before the next command is run, forcing it to reinitialize
any cached connection settings.
Run a Login on the Perforce Server
User' password
Login options (see remarks in help file)
Login as user (see remarks in help file)
Success/Failure
p4 help login
login -- Log in to Perforce by obtaining a session ticket
p4 login [-a -p] [-h <host> user]
p4 login [-s]
The login command enables a user to access Perforce until the session
expires or the user logs out.
When a user logs in to Perforce, they are prompted for a password
If they enter the correct password, they are issued a ticket. The
ticket expires when the default timeout value has been reached and
is valid only for the host machine where the 'login' command was
executed (see below for exception).
The ticket can be used anywhere that a password can be used.
Example: p4 -P <ticket value> changes -m1
The -a flag causes the server to issue a ticket that is valid on all
host machines.
The -h flag causes the server to issue a ticket that is valid on the
specified host (IP address). This flag can only be used when the
login request is for another user.
The -p flag displays the ticket, but does not store it on the client
machine.
The -s flag displays the status of the current ticket (if there is
one).
Specifying a username as an argument to 'p4 login' requires 'super'
access, which is granted by 'p4 protect'. In this case, 'p4 login'
does not prompt for the password (you must already be logged in).
Login to the Perforce Server
User' password
Login options (see remarks in help file)
Success/Failure
p4 help login
login -- Log in to Perforce by obtaining a session ticket
p4 login [-a -p] [-h <host> user]
p4 login [-s]
The login command enables a user to access Perforce until the session
expires or the user logs out.
When a user logs in to Perforce, they are prompted for a password
If they enter the correct password, they are issued a ticket. The
ticket expires when the default timeout value has been reached and
is valid only for the host machine where the 'login' command was
executed (see below for exception).
The ticket can be used anywhere that a password can be used.
Example: p4 -P <ticket value> changes -m1
The -a flag causes the server to issue a ticket that is valid on all
host machines.
The -h flag causes the server to issue a ticket that is valid on the
specified host (IP address). This flag can only be used when the
login request is for another user.
The -p flag displays the ticket, but does not store it on the client
machine.
The -s flag displays the status of the current ticket (if there is
one).
Specifying a username as an argument to 'p4 login' requires 'super'
access, which is granted by 'p4 protect'. In this case, 'p4 login'
does not prompt for the password (you must already be logged in).
Automate the Login to the Perforce Server
User' password
Login options (see remarks in help file)
Login as user (see remarks in help file)
Success/Failure
Runs the login process. If the server is using ticket based
authentication, actually runs the logn three times. Once to
login and update the ticket file, once to get the ticket from
the server and finally once to get the ticket expiration data.
Logout of the Perforce server
Logout options (see remarks in help file)
Success/Failure
p4 help logout
logout -- Log out from Perforce by removing or invalidating a ticket.
p4 logout [-a]
The logout command removes the ticket on the client. To resume using
Perforce, the user must log in again.
The -a flag invalidates the ticket on the server, which will log out
all users of the ticket.
Run the client side command trust
trust options (see remarks in help file)
Success/Failure
p4 trust -h
trust -- Establish trust of an SSL connection
p4 trust [ -l -y -n -d -f -r -i <fingerprint> ]
Establish trust of an SSL connection. This client command manages
the p4 trust file. This file contains fingerprints of the keys
received on ssl connections. When an SSL connection is made, this
file is examined to determine if the SSL connection has been used
before and if the key is the same as a previously seen key for that
connection. Establishing trust with a connection prevents undetected
communication interception (man-in-the-middle) attacks.
Most options are mutually exclusive. Only the -r and -f options
can be combined with the others.
The -l flag lists existing known fingerprints.
Without options, this command will make a connection to a server
and examine the key if present, if one cannot be found this command
will show a fingerprint and ask if this connection should be trusted.
If a fingerprint exists and does not match, an error that a possible
security problems exists will be displayed.
The -y flag will cause prompts to be automatically accepted.
The -n flag will cause prompts to be automatically refused.
The -d flag will remove an existing trusted fingerprint of a connection.
The -f flag will force the replacement of a mismatched fingerprint.
The -i flag will allow a specific fingerprint to be installed.
The -r flag specifies that a replacement fingerprint is to be
affected. Replacement fingerprints can be used in anticipation
of a server replacing its key. If a replacement fingerprint
exists for a connection and the primary fingerprint does not match
while the replacement fnigerprint does, the replacement fingerprint
will replace the primary. This flag can be combined with -l, -i,
or -d.
Set the current user's password on the Perforce server.
User's old password
User's new password
Success/Failure
p4 help passwd
passwd -- Set the user's password on the server (and Windows client)
p4 passwd [-O oldPassword -P newPassword] [user]
'p4 passwd' sets the user's password on the server.
After a password is set for a user, the same password must be set on
the client in the environment variable $P4PASSWD to enable the user
to use all Perforce client applications on that machine. (On Windows,
you can use 'p4 passwd' to configure the password in the environment.)
'p4 passwd' prompts for both the old password and the new password
with character echoing turned off. To delete the password, set it to
an empty string.
The -O flag provides the old password, avoiding prompting.
The -P flag provides the new password, avoiding prompting.
If you are using ticket-based authentication, changing your password
automatically invalidates all of your tickets and logs you out.
Specifying a username as an argument to 'p4 passwd' requires 'super'
access granted by 'p4 protect'.
Set the a user's password on the Perforce server.
User's old password
User's new password
User receiving new password
Success/Failure
p4 help passwd
passwd -- Set the user's password on the server (and Windows client)
p4 passwd [-O oldPassword -P newPassword] [user]
'p4 passwd' sets the user's password on the server.
After a password is set for a user, the same password must be set on
the client in the environment variable $P4PASSWD to enable the user
to use all Perforce client applications on that machine. (On Windows,
you can use 'p4 passwd' to configure the password in the environment.)
'p4 passwd' prompts for both the old password and the new password
with character echoing turned off. To delete the password, set it to
an empty string.
The -O flag provides the old password, avoiding prompting.
The -P flag provides the new password, avoiding prompting.
If you are using ticket-based authentication, changing your password
automatically invalidates all of your tickets and logs you out.
Specifying a username as an argument to 'p4 passwd' requires 'super'
access granted by 'p4 protect'.
Create a P4Command that can be run on the connection
Command name, i.e. 'sync'
Flag to create tggged output
The arguments for the command
Create a P4.P4MapApi object to be used on the current server connection
What API level does the server support
The results of the last command executed
Specifies user credentials for a specific connection.
The type of the depot.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
An 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: 'local', 'stream', 'remote', 'spec', or 'archive'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
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
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
A depot specification in a Perforce repository.
Read the fields from the tagged output of a depot command
Tagged output from the 'depot' command
Parse the fields from a depot specification
Text of the depot specification in server format
Format of a depot specification used to save a depot to the server
Convert to specification in server format
Read the fields from the tagged output of a depots command
Tagged output from the 'depots' command
The types of diffs returned by the server.
File contents are different.
File contents are identical but file types are different.
The left file in the diff has no target file at the
specified name or revision to pair with for a diff.
The right file in the diff has no source file at the
specified name or revision to pair with for a diff.
File content and file types are identical.
p4 help diff2
diff2 -- Compare one set of depot files to another
p4 diff2 [options] fromFile[rev] toFile[rev]
p4 diff2 [options] -b branch [[fromFile[rev]] toFile[rev]]
p4 diff2 [options] -S stream [-P parent] [[fromFile[rev]] toFile[rev]]
options: -d<flags> -q -t -u
'p4 diff2' runs on the server to compare one set of depot files (the
'source') to another (the 'target'). Source and target file sets
can be specified on the 'p4 diff2' command line or through a branch
view.
With a branch view, fromFile and toFile are optional; fromFile limits
the scope of the source file set, and toFile limits the scope of the
target. If only one file argument is given, it is assumed to be
toFile.
fromFile and toFile can include revision specifiers; by default, the
head revisions are diffed. See 'p4 help revisions' for details
about specifying file revisions.
'p4 diff2' precedes each diffed file pair with a header line of the
following form:
==== source#rev (type) - target#rev (type) ==== summary
A source or target file shown as '<none>' means there is no file
at the specified name or revision to pair with its counterpart.
The summary status is one of the following: 'identical' means file
contents and types are identical, 'types' means file contents are
identical but the types are different, and 'content' means file
contents are different.
The -b flag makes 'p4 diff2' use a user-defined branch view. (See
'p4 help branch'.) The left side of the branch view is the source
and the right side is the target.
The -S flag makes 'p4 diff2' use a stream's branch view. (See 'p4
help stream'.) The stream is the source, and its parent is the
target. -P can be used to specify a parent stream other than the
stream's actual parent.
The -d<flags> modify the output of diffs as follows:
-dn (RCS)
-dc[n] (context)
-ds (summary)
-du[n] (unified)
-db (ignore whitespace changes)
-dw (ignore whitespace)
-dl (ignore line endings).
The optional argument to -dc specifies number of context lines.
The -q omits files that have identical content and types and
suppresses the actual diff for all files.
The -t flag forces 'p4 diff2' to diff binary files.
The -u flag uses the GNU diff -u format and displays only files
that differ. The file names and dates are in Perforce syntax, but
but the output can be used by the patch program.
A diff between depot files in a Perforce repository.
Read the fields from the tagged output of a diff2 command
Tagged output from the 'diff2' command
A user group on a Perforce Server, represented by a P4 Group spec.
p4 help group
group -- Change members of user group
p4 group [-a] name
p4 group -d [-a] name
p4 group -o name
p4 group -i [-a]
Create a group or modify the membership of an existing group.
A group can contain users and other groups. The group specification
is put into a temporary file and the editor (configured by the
environment variable $P4EDITOR) is invoked.
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.
Each group has MaxResults, MaxScanRows, and MaxLockTime fields,
which limit the resources committed to operations performed by
members of the group. For these fields, 'unlimited' or 'unset'
means no limit for that group. An individual user's limit is the
highest of any group with a limit to which he belongs, unlimited if
any of his groups has 'unlimited' for that field, or unlimited
if he belongs to no group with a limit. See 'p4 help maxresults'
for more information on MaxResults, MaxScanRows and MaxLockTime.
Each group also has a Timeout field, which specifies how long (in
seconds) a 'p4 login' ticket remains valid. A value of 'unset' or
'unlimited' is equivalent to no timeout. An individual's timeout is
the highest of any group with a limit to which he belongs, unlimited
if any of his groups has 'unlimited' for the timeout value, or
unlimited if he belongs to no group with a limit. See 'p4 help login'
for more information.
Each group has a PasswordTimeout field, which determines how long a
password remains valid for members of the group.
The -d flag deletes a group.
The -o flag writes the group specification to standard output. The
user's editor is not invoked.
The -i flag reads a group specification from standard input. The
user's editor is not invoked. The new group specification replaces
the previous one.
The -a flag enables a user without 'super' access to modify the group
if that user is an 'owner' of that group. Group owners are specified
in the 'Owners' field of the group spec.
All commands that require access granted by 'p4 protect' consider a
user's groups when calculating access levels.
'p4 group' requires 'super' access granted by 'p4 protect' unless
invoked with the '-a' flag by a qualified user.
A group specification in a Perforce repository.
Create a group supplying the name.
Create a group providing all of the properties
Read the fields from the tagged output of a group command
Tagged output from the 'user' command
Parse the fields from a group specification
Text of group user specification in server format
# A Perforce Group Specification.
#
# Group: The name of the group.
# MaxResults: Limits the rows (unless 'unlimited' or 'unset') any one
# operation can return to the client.
# See 'p4 help maxresults'.
# MaxScanRows: Limits the rows (unless 'unlimited' or 'unset') any one
# operation can scan from any one database table.
# See 'p4 help maxresults'.
# MaxLockTime: Limits the time (in milliseconds, unless 'unlimited' or
# 'unset') any one operation can lock any database table when
# scanning data. See 'p4 help maxresults'.
# Timeout: A time (in seconds, unless 'unlimited' or 'unset')
# which determines how long a 'p4 login'
# session ticket remains valid (default is 12 hours).
# PasswordTimeout:
# A time (in seconds, unless 'unlimited' or 'unset')
# which determines how long a 'p4 password'
# password remains valid (default is unset).
# Subgroups: Other groups automatically included in this group.
# Owners: Users allowed to change this group without requiring super
# access permission.
# Users: The users in the group. One per line.
Format of a user specification used to save a user to the server
Convert to specification in server format
The specification for the group
The name of the group.
Limits the rows (unless 'unlimited' or 'unset') any one
operation can return to the client.
Limits the rows (unless 'unlimited' or 'unset') any one
operation can scan from any one database table.
Limits the time (in milliseconds, unless 'unlimited' or
'unset') any one operation can lock any database table when
scanning data.
A time (in seconds, unless 'unlimited' or 'unset')
which determines how long a 'p4 login'
session ticket remains valid (default is 12 hours).
A time (in seconds, unless 'unlimited' or 'unset')
which determines how long a 'p4 password'
password remains valid (default is unset).
Users allowed to change this group without requiring super
access permission.
The users in the group.
Other groups automatically included in this group.
A general-purpose counter or named variable in a Perforce repository.
A versioned object that describes an individual file in a Perforce repository.
Identifies one or more specific versioned objects in a Perforce repository.
Create a list of FileSpec objects from a list of client paths
List of paths
List of FileSpec objects
Create a list of FileSpec objects from a list of depot paths
List of paths
List of FileSpec objects
Create a list of FileSpec objects from a list of local paths
List of paths
List of FileSpec objects
Create a list of FileSpec objects from a list of local paths
List of paths
List of FileSpec objects
Create a copy of a filespec without a version
Copies a list of FileSpec objects without vesions
List of FileSpecs
List of FileSpec objects
Create an array of FileSpec objects from a list of local paths
List of paths
List of FileSpec objects
Create an array of FileSpec objects from a list of local paths
List of paths
List of FileSpec objects
Copy the non-null entries into a new string array.
Copy the non-null entries into a new string array
with the paths escaped for special characters
Copy the non-null entries into a new string array
with the paths escaped for special characters
Copy the non-null entries into a new string array.
Copy the non-null entries into a new string array containing the paths.
Copy the non-null entries into a new string array containing the paths
escaped for special characters
Copy the non-null entries into a new string array containing the local paths
escaped for special characters
Correlates file lines with revision information.
Describes a Perforce file revision in detail, including the changelist
number and associated description, action, user, etc. data.
Convert to a string of the format ... #{rev} change {change} {action} on {date} {user}@{client} (type) '{desc}'
Convert to a string of the format ... #{rev} change {change} {action} on {date}[ {time}] {user}@{client} (type) '{desc}'
Include the time as well as the date
Describes an integration, specifying the from file and how
the integration was done.
Represents submitted or pending integrations.
Specifies whether this line match is an exact match,
or a context (before or after) match.
Specifies matching lines in Perforce managed files.
Describes the pending or completed action related to open,
resolve, or integration for a specific file.
None.
Opened for add.
Opened for branch.
Opened for edit.
Opened for integrate.
File has been deleted.
file was integrated from partner-file, and partner-file
had been previously deleted.
file was integrated into partner-file, and file had been
previously deleted.
File has been synced.
File has been updated.
File has been added.
file was integrated into previously nonexistent partner-file,
and partner-file was reopened for add before submission.
File has been refreshed.
File was integrated from partner-file, accepting yours.
File was integrated into partner-file, accepting yours.
File has been abandoned.
None.
File is opened for move.
File has been added as part of a move.
File has been deleted as part of a move.
File was integrated from partner-file, accepting theirs
and deleting the original.
File was integrated into partner-file, accepting merge.
File has not been resolved.
File was integrated from partner-file, accepting theirs.
File was integrated into partner-file, accepting theirs.
File was integrated from partner-file, accepting merge.
File was integrated into partner-file, accepting merge.
file was integrated from partner-file, and file was edited
within the p4 resolve process. This allows you to determine
whether the change should ever be integrated back; automated
changes (merge from) needn't be, but original user edits
(edit from) performed during the resolve should be.
File was integrated into partner-file, and partner-file was
reopened for edit before submission.
File was purged.
File was imported.
File did not previously exist; it was created as a copy of
partner-file.
Partner-file did not previously exist; it was created as a
copy of file.
File was reverted.
Class summarizing the use of this file by another user.
Specifies other users who have a particular file open.
Metadata for a specific file stored in a Perforce repository.
Cast a FileSpec to FileMetatData
Cast a FileSpec to FileMetatData
The location of the file in the depot
The location of the file in the client's file system,
may be either a ClientPath or a LocalPath
Describes how, or if a file has been resolved.
The action used in resolving the file.
Specifies how file resolve operations were completed or will
potentially be completed.
Flags to define the base file type.
An unspecified base file type.
Client Use: newlines translated.
Server Storage: deltas in RCS format.
Client Use: raw bytes.
Server Storage: compressed binary.
Client Use: symbolic link.
Server Storage: deltas in RCS format.
Client Use: Mac resource + data.
Server Storage: compressed AppleSingle.
Client Use: Mac resource fork.
Server Storage: compressed binary.
Client Use: newlines translated.
Server Storage: deltas in RCS format
stored as UTF-8.
Client Use: newlines translated
client file UTF-16
Server Storage: deltas in RCS format
stored as UTF-8
Files of type utf16 are stored in the depot in UTF-8.
These files are in utf16 in the client workspace.
The automatic type detection requires a BOM be present
at the start of the file. Files without a BOM are
assumed to be in client byte order. When utf16 files
are written to a client, they are written with a BOM
in client byte order.
Flags to specify file type modifiers.
No flags.
+m always set modtime on client (overrides
client's nomodtime).
+w always writable on client.
+x exec bit set on client.
+k $Keyword$ expansion of Id, Header, Author
Date, DateTime, Change, File, Revision.
+ko $Keyword$ expansion of ID, Header only.
+l exclusive open: disallow multiple opens.
+C server stores compressed file per revision.
+D server stores deltas in RCS format.
+F server stores full file per revision.
+S server stores only single head revision.
+X server runs archive trigger to access files
Specifies a Perforce file type for a managed file.
P4Server
Represents the connection to a Perforce Server using the the P4 Bridge
DLL. It wraps the calls exported by the DLL and transforms the data
types exported by the DLL as native C#.NET data types.
This file contains the internal data a methods that are not part of the
public interface
P4Server
Represents the connection to a Perforce Server using the the P4 Bridge
DLL. It wraps the calls exported by the DLL and transforms the data
types exported by the DLL as native C#.NET data types.
Is the server Unicode enabled
What API level does the server support
Does the server require the login command be used
Marshall a returned pointer as a UTF-16 encoded string
Native pointer to the string
UTF-16 String
Marshall a returned pointer as a UTF-8 encoded string
Native pointer to the string
UTF-16 String
Marshall a returned pointer as a UTF-8 encoded string
Native pointer to the string
UTF-16 String
Translate a returned string based on the current encoding
Native pointer to the string
UTF-16 String
Convert a returned c++ byte pointer (void *) to a byte[]
byte pointer
byte count
Converted byte[]
Marshal a String[] into an array of native pointers to strings
in the correct encoding for Unicode enabled servers
The args to encode
Count of args to encode
Array of IntPtrs to encoded strings
Marshal a String into the correct encoding to pass to a Unicode
enabled server.
String to encode
IntPtr of the encoded string
Marshal a String into the correct encoding to pass to a Unicode
enabled server.
String to encode
IntPtr of the encoded string
Handle (pointer) to the P4BridgeServer wrapped by this P4Server
Internal creator for unit testing other classes
Set the character set encoding used to pass parameters to a Unicode
enabled server.
This is handled automatically after connecting with a P4 server.
Holds the call back passed to the bridge used to receive the
individual key:value pairs for an object
Pinned function pointer for the delegate passed to the dll
Used to build up an object as its key:value pairs are received
Delegate used to send real time tagged results generated by a
command
We receive multiple calls for each StrDict object, one for each
key:value pair that will get combined into a single TaggedObject used
to represent an 'object'. This client delegate receives a single
TaggedObject representing the complete object.
Internal callback used to receive the individual Key:Value pair
data for an object
We receive multiple calls for each StrDict object, one for each
key:value pair that will get combined into a single TaggedObject used
to represent an 'object'. Object IDs are unique for the objects
returned by a single command, but are not unique across commands.
Object ID assigned by the bridge
Key for this entry
Value for this entry
Pinned function pointer for the delegate passed to the dll
Internal callback used to receive the raw data.
The text data pointed to by a char* is marshaled into a String
Severity level
char* pointer for error message
Set the callback used to return real time Errors.
Holds the call back passed to the bridge used to receive the
raw data
Pinned function pointer for the delegate passed to the dll
Internal callback used to receive the raw data.
The text data pointed to by a char* is marshaled into a String
message level
char* pointer to message
Set the callback used to return real time info output.
Holds the call back passed to the bridge used to receive the
raw binary data
Pinned function pointer for the delegate passed to the dll
Internal callback used to receive the raw text data.
The text data pointed to by a char* is marshaled into a String
char* pointer
Set the callback used to return real time text output.
Far large output, the client may receive multiple callbacks.
Simply concatenate the data to get the complete data.
Holds the call back passed to the bridge used to receive the
raw binary data
Pinned function pointer for the delegate passed to the dll
Internal callback used to receive the raw binary data.
The binary data pointed to by a void* is marshaled into a byte[]
void* pointer
Byte count
Set the callback used to return real time binary output.
Far large output, the client may receive multiple callbacks.
Simply concatenate the data to get the complete data.
Holds the call back passed to the bridge used to receive input
prompts from the server
Pinned function pointer for the delegate passed to the dll
Holds the call back passed to the bridge used to receive resolve callbacks
with a ClientMerge object from the server
Pinned function pointer for the delegate passed to the dll
Holds the call back passed to the bridge used to receive resolve callbacks
with a ClientResolve object from the server
Pinned function pointer for the delegate passed to the dll
Create a P4BridgeServer used to connect to the specified P4Server
Host:port for the P4 server.
User name for the login.
Can be null/blank if only running commands that do not require
a login.
Password for the login. Can be null/blank if
only running commands that do not require a login.
Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.
Create a P4BridgeServer using the PUC specified by the environment
or a p4config file if one exists.
Current working Directory. Can be null/blank if
not connecting to the Perforce server using a P4Config file.
Create a P4BridgeServer used to connect to the specified P4Server
Host:port for the P4 server.
User name for the login.
Can be null/blank if only running commands that do not require
a login.
Password for the login. Can be null/blank if
only running commands that do not require a login.
Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.
Current working Directory. Can be null/blank if
not connecting to the Perforce server using a P4Config file.
Create a P4BridgeServer used to connect to the specified P4Server
Host:port for the P4 server.
User name for the login.
Can be null/blank if only running commands that do not require
a login.
Password for the login. Can be null/blank if
only running commands that do not require a login.
Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.
Run a login command on the server
User's password
Success/Failure
If the server requires a login (security level >= 3), this will
prompt for the password. If login is not required, the command will
just return with a result saying that login is not required.
Run a logout command on the server
The -a flag invalidates the ticket on the server.
Success/Failure
If the server requires a login (security level >= 3), this will
logout the user and remove the local ticket.
Finalizer
For IDispose
Reconnect to the server in the event the connection is lost
Close the connection to a P4 Server
Called by the Dispose() method
Maximum time for a command to run before timing out;
Run a P4 command on the P4 Server
If the command fails, the error output will contain one or more
errors generated by the P4 server.
Command code
Use tagged output for the results
Arguments for the command
Argument count
Success/Failure
Cancel a running command
Unique Id for the run of the command
Release the UI created for a command after it has been completed
Unique Id for the run of the command
Get the tagged output generated by a command
A list of TaggedObjects comprising the tagged output.
Holds the call back passed to the bridge used to receive the
raw data
Get a list of errors (if any) generated by a command
A list of P4ClientErrors, null if no errors
Get the information messages generated by the previous command
Each message is formatted as follows
l:Message text
where l is a single digit representing the message level
List of messages
Get the complete text results for the last command
Get the complete binary results for the last command
The binary data
Broadcast a the command line (cmd and args) on the CommandEcho event
Used to echo an executed command line back to the client
The P4 command.
The flags and parameters for the command.
Broadcast a string on the CommandEcho event
Used to echo command data back to the client
The string.
The data set for use by a command
If a command requires data not passed on the command line, such as
a client spec, it is passed to the P$ server by setting the data
set in the P4 api.
Delegate used to process prompts for input from the server.
Delegate used to provide a custom handler for Resolve callbacks passing a ClientMerge object from the p4api.
Delegate used to provide a custom handler for Resolve callbacks passing a ClientResolve object from the p4api.
The parameters used by the connection
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
The config file that will be used by a given directory
Get an environment setting used by the server, such as user, client, ..
The name of the environment varible
Set an environment setting used by the server, such as user, client, ..
The name of the environment variable
The new value for the environment variable
Use the C++ API to determine if a file will be ignored
The local path of the file
true if the file will be ignored
The results of the last command executed on this thread
Get the version of the p4.net assembly
Get the error message generated by the previous connection (if any)
Get the error message generated by the previous connection (if any)
from the bridge dll.
Need to use Unicode when marshalling to/from the P4 server
What API level does the server support
The server requires a client to use the login command to pass credentials.
Event to broadcast tagged output
Broadcast errors received
Broadcast event for info results
Broadcast event for text results
Broadcast event for binary data
Broadcast event for text results
The client workspace used by the connection
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
The user name used by the connection
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
The hostname:port used by the connection
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
The user's password used by the connection
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
The program name used by the connection
The program name and version are recorded in the server logs when
accessed by the client
The program version used by the connection
The program name and version are recorded in the server logs when
accessed by the client
The current working directory (cwd) used by the p4 server
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
The character set used by the connection
The character set used to connect to Unicode servers is set by the
bridge dll automatically (possibly overridden by P4CHARSET) based
on the current Windows code page.
The config file used by the connection
P4Encoding
How do we encode Unicode UTF-16 strings, the .NET internal format
before sending them to the bridge dll?
Delegate used to send tagged output as it is generated.
This delegate will send a complete object after all of its fields
have been received by the callback from the bridge dll.
Delegate used to send errors as they are generated.
This delegate will send a block of data for each call received by
the callback from the bridge dll.
Command Id of the command causing the error
Severity of the error
Error number for the error
Error message
Delegate used to send Info Results as they are generated.
This delegate will send a block of data for each call received by
the callback from the bridge dll.
Server supplied message level
Server supplied message data
Delegate used to send Text Results as they are generated.
This delegate will send a block of data for each call received by
the callback from the bridge dll.
Text results generated by the command
Delegate used to send binary output as it is generated.
This delegate will send a block of data for each call received by
the callback from the bridge dll.
Binary data generated by a command
Delegate used to commands as they are executed.
Command line executed by the command
Delegate used to provide a custom handler for input prompts from the p4api.
Delegate used to provide a custom handler for Resolve callbacks passing a ClientMerge object from the p4api.
Delegate used to provide a custom handler for Resolve callbacks passing a ClientResolve object from the p4api.
Generic interface used to an event logger. In short, messages are
logged by:
1) Level. The lower the level, the more sever the level,
0 fatal
1 error
2 warning
3 information
4+ debugging messages
2) Source. A string specifying the origin of the message, ie P4Server
3) Message. The text of the message.
Allows a client to monitor the execution of a command. It allow the client to
cancel the command if it takes to long to complete or display a UI to allow the
user to cancel the command.
A command is starting
Server running the command
CmdId of the command
Command Line for the command for display purposes
The command has completed dismiss any UI or timeouts
CmdId of the command that completed
Note, it is OK for the API might send this multiple times with the,
same cmdId to ensure that any UI displayed by the client iss dismissed.
Class wrapper for the definitions of delegates required to model the
callbacks from the bridge dll.
Delegate definition for the Logging callback from the dll.
Log Level Lower values are more serious
than higher values.
Name of the cpp file containing the call.
Line number in the cpp file of the call.
Descriptive message to be logged.
Delegate definition for the tagged output delegate.
Each call of this delegate by the bridge provides a single Key:Value
pair for the current object. When all the Key:Value pairs for an
object have been sent, the bridge will make one final call with null
for the values of the key and value to signify it is complete. Each
object generated by a command will have an object ID that unique for
that command.
Id if the command making the callback
Object ID for the object
The Key of this Key:Value pair
The Key of this Key:Value pair
Delegate definition for the error callback.
Id if the command making the callback
Severity of the error
Error Message
Delegate definition for the info results callback.
The "info" results generally are the output of commands that are run
not using tagged protocol
Id if the command making the callback
Delegate definition for the text results callback.
If this callback is used, the text output generated by a command
will be delivered by one or more call to the supplied delegate.
It multiple calls are made, the entire text is obtained by
concatenating the text from each call.
Id if the command making the callback
Text output produced by the command
Delegate definition for the binary results callback.
If this callback is used, the binary output generated by a command
will be delivered by one or more call to the supplied delegate.
It multiple calls are made, the entire output is obtained by
concatenating the data from each call.
Id if the command making the callback
Binary data generated by the command
The size in bytes of the data
Delegate definition for the prompt callback.
Id if the command making the callback
Prompt message from the server
Character buffer to receive the response
Size of the buffer
Display flog
Delegate definition for the Resolve callback passing a CLientMerge object.
P4ClientMerge used to handle the resolve
Resolve result
Delegate definition for the Resolve callback passing a CLientResolve object.
Id if the command making the callback
P4ClientReslove used to handle the resolve
Preview only
Resolve result
Class containing the DLL imports for the P4Bridge DLL.
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
Host:port for the P4 server.
User name for the login.
Can be null/blank if only running commands that do not require
a login.
Password for the login. Can be null/blank if
only running commands that do not require a login.
Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.
Function pointer for the logging callback. Can
be null if logging is not desired.
Handle (pointer) to the P4BridgeServer
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
Host:port for the P4 server.
User name for the login.
Can be null/blank if only running commands that do not require
a login.
Password for the login. Can be null/blank if
only running commands that do not require a login.
Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.
Function pointer for the logging callback. Can
be null if logging is not desired.
Handle (pointer) to the P4BridgeServer
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
Host:port for the P4 server.
User name for the login.
Can be null/blank if only running commands that do not require
a login.
Password for the login. Can be null/blank if
only running commands that do not require a login.
Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.
Flag to pass to the trust command.
Fingerprint to pass to the trust
command.
Function pointer for the logging callback. Can
be null if logging is not desired.
Handle (pointer) to the P4BridgeServer
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
Host:port for the P4 server.
User name for the login.
Can be null/blank if only running commands that do not require
a login.
Password for the login. Can be null/blank if
only running commands that do not require a login.
Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.
Flag to pass to the trust command.
Fingerprint to pass to the trust
command.
Function pointer for the logging callback. Can
be null if logging is not desired.
Handle (pointer) to the P4BridgeServer
Get the error message generated by the previous connection (if any)
Error Message. Null if no error occurred
Sets the character set used by the P4Bridge server if connection is
to Unicode enabled server.
Handle of the P4BridgeServer
Character set to use for Unicode data
exchanged with the P4 Server
Character set to use for files
stored in
the client' host file space
null if no error, otherwise a pointer to an error
message.
Close the connection
P4BridgeServer Handle
Close the connection
P4BridgeServer Handle
Check if the server supports Unicode
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
P4BridgeServer Handle
Check to see what API level the server supports
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
P4BridgeServer Handle
Check if the server requires the login command be used
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
P4BridgeServer Handle
Check if the server supports extended submit options (2006.2 higher)
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
P4BridgeServer Handle
Run a command on the P4 Server
The A version is used to pass ASCII parameters
P4BridgeServer Handle
Command. i.e "fstat"
Unique Id for the run of the command
If true, use tagged protocol the receive the
output
Arguments for the command
Argument count
Run a command on the P4 Server
The W version is used to pass Unicode (wide) parameters
P4BridgeServer Handle
Command. i.e "fstat"
Unique Id for the run of the command
If true, use tagged protocol the receive the
output
Arguments for the command
Argument count
Cancel a running command
P4BridgeServer Handle
Unique Id for the run of the command
Release the UI created for a command after it has been completed
P4BridgeServer Handle
Unique Id for the run of the command
Set the callback for tagged output
P4BridgeServer Handle
Pinned pointer to the callback delegate
Set the callback for error output
P4BridgeServer Handle
Pinned pointer to the callback delegate
Set the callback for Info (non tagged) output
P4BridgeServer Handle
Pinned pointer to the callback delegate
Set the callback for text output
P4BridgeServer Handle
Pinned pointer to the callback delegate
Set the callback for binary output
P4BridgeServer Handle
Pinned pointer to the callback delegate
Set the call back to receive input prompts from the sever
P4BridgeServer Handle
Pinned pointer to the callback delegate
Get the tagged output for the last command
P4BridgeServer Handle
StrDictListIterator Handle (pointer) used to read the data
Get the error output for the last command
P4BridgeServer Handle
P4ClientErrorList Handle (pointer) used to read the data
Get the info output for the last command
P4BridgeServer Handle
Handle (pointer) to the string data
Get the text output for the last command
P4BridgeServer Handle
Handle (pointer) to the string data
Get the byte count for the binary output for the last command
P4BridgeServer Handle
Handle (pointer) to the data bytes
Get the binary output for the last command
P4BridgeServer Handle
Handle (pointer) to the data bytes
Set the data set using Unicode data
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
New Unicode data set
Set the data set using Unicode data
P4BridgeServer Handle
New ASCII data set
Read the data set
The data will be encoded in ASII or Unicode, depending on the
server configuration and character set set previously with
SetCharacterSet().
P4BridgeServer Handle
The data in the data set
Set the connection parameters using Unicode strings.
P4BridgeServer Handle
New port
New workspace
New password
New workspace
Set the connection parameters using ASCII strings.
P4BridgeServer Handle
New port
New workspace
New password
New workspace
Set the client workspace using a Unicode string
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
Client Workspace name
Set the client workspace using a ASCII string
P4BridgeServer Handle
Client Workspace name
Get the name of the client workspace
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
Client workspace name
Set the user name using a Unicode string
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
User name
Set the user name using a ASCII string
P4BridgeServer Handle
User name
Get the name of the current user
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
The user's name
Set the connection string using a Unicode string
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
Connection String
Set the connection string using a ASCII string
P4BridgeServer Handle
Connection String
Get the connection string.
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
host:port used by the connection
Set the user's password using a Unicode string
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
User's password
Set the user's password using an ASCII string
P4BridgeServer Handle
User's password
Get the password used for the connection
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
The password
Gets the current working directory for the P4BridgeServer.
P4BridgeServer Handle
The current working directory for the P4BridgeServer.
Sets the current working directory for the P4BridgeServer using a Unicode string.
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
The new working directory
Sets the current working directory for the P4BridgeServer using an ASCII string.
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
The new working directory
Set the program name using a Unicode string
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
program name
Set the program name using an ASCII string
P4BridgeServer Handle
program name
Get the program name used for the connection
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
program name
Set the program version using a Unicode string
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
program version
Set the program version using an ASCII string
P4BridgeServer Handle
program version
Get the program version used for the connection
The encoding should match that set by SetCharacterSet()
P4BridgeServer Handle
program version
Get the character set used for the connection.
Pointer to the P4BridgeServer
The ANSI string representing the characterset name
Get the config file for the current connection, if any.
Pointer to the P4BridgeServer
The config file
Get the config file for the specified directory, if any.
Pointer to the P4BridgeServer
The config file
Get the Next item (a StrDict based object)
StrDictListIterator Handle
StrDictList Handle, null if end of list
Get the next dictionary entry for the current item.
StrDictListIterator Handle
Handle to a Key:Value pair
Delete the StrDictListIterator object when it is no longer needed
StrDictListIterator Handle
Retrieve the key
KeyValuePair Handle
Key string
Retrieve the value
KeyValuePair Handle
String value
Severity of the error
P4ErrorList Handle
Severity level
Generic code of the error
P4ErrorList Handle
Generic error code
Get the error's message.
P4ErrorList Handle
Error Message
Get the next error in the list
P4ErrorList Handle
null indicates the end of the list
Class containing the DLL imports for the P4Bridge DLL.
Class containing the DLL imports for the P4Bridge DLL.
Class wrapping command execution.
Command opcode
The arguments used by the command
Tagged protocol flag
Capture info results so they can be reformatted
Create a new command
Create a new command
Constructer
Connection to the target Repository
Command String i.e 'submit'
Run in tagged protocol
Arguments for the command
Constructer
Target Repository
Command String i.e 'submit'
Run in tagged protocol
Arguments for the command
Constructer
Target Repository
Command String i.e 'submit'
Run in tagged protocol
Arguments for the command
Constructer
Target P4Server
Command String i.e 'submit'
Run in tagged protocol
Arguments for the command
Constructer
Target P4Server
Command String i.e 'submit'
Run in tagged protocol
Arguments for the command
Use the infoResultsReceived event to build up a list of info data.
level of the message
message text
Respond to a prompt from the server for input
Run the command supplying additional arguments
Additional arguments inserted in front of the current arguments
Success/Failure
Run the command using the existing arguments
Run the command supplying additional arguments
Additional arguments inserted in front of the current arguments
Dispose of any resources
Unique Id set each time command is run
Get the info results from the command execution
Get the error results from the command execution
Get the text output from the command execution
Get the tagged results from the command execution
Get the binary from the command execution
Command String i.e 'submit'
Arguments for the command
Run in tagged protocol
Dictionary of responses to prompts from the server, where the key
is the expected prompt from the server and the value is the
desired response.
Data to be processed by the command
Base class for exceptions caused by run time errors from the server.
They ca be disabled, by setting the MinThrowLevel to
ErrorSeverity.E_NOEXC.
Create a new P4Exception
Severity level
Error message
Create a new P4Exception
Severity level
Error message
Next error in sequence
Create a new P4Exception
Severity level
Error message
Next error in sequence
Create a new P4Exception
Client error causing the exception
Create a new P4Exception
Client error causing the exception
Create a list of new P4Exceptions
The list of errors which caused the exception
Create a list of new P4Exceptions
The list of errors which caused the exception
Create a list of new P4Exceptions
The list of errors which caused the exception
The info output of the command which caused the exception
Create a list of new P4Exceptions
The list of errors which caused the exception
The info output of the command which caused the exception
Create and throw an exception if it exceeds the MinThrowLevel
Severity level
Error message
Create and throw an exception if it exceeds the MinThrowLevel
Severity level
Error message
Create and throw an exception if it exceeds the MinThrowLevel
Client error causing the exception
Create and throw an exception if it exceeds the MinThrowLevel
Client error causing the exception
Throw if any error in the list exceeds minLevel
List of client errors causing the exception
Throw if any error in the list exceeds minLevel
List of client errors causing the exception
Throw if any error in the list exceeds minLevel
List of client errors causing the exception
Throw if any error in the list exceeds minLevel
List of client errors causing the exception
If more than one error was returned by a command, the next
error in the list.
Severity of the error
Error number from the C++ API
Error message
Error message
Error message
Minimum error to cause an exception to be thrown
P4MapApi: .NET wrapper for the MapApi object in the p4api dll.
Create a new P4MapApi
The P4Server on which the map will be used
The server is needed to know whether or not it is necessary to translate
strings to/from Unicode
Wrap the pointer to MapApi object in a P4MapApi
The P4Server on which the map will be used
The MapApi pointer to wrap
The server is needed to know whether or not it is necessary to translate
strings to/from Unicode
Delete the P4MapApi object and free the native object from the dll.
Helper function to create a new MapApi object.
IntPtr to the new object
Call DeletMapApi() on the returned pointer to free the object
Helper function to delete a MapApi object allocated by CreateMApApi().
IntPtr for the object to be deleted
Clear all the data in the map
Return the left side of the specified entry in the map
Index of the desired entry
String representing the left side of the entry
Return the right side of the specified entry in the map
Index of the desired entry
String representing the right side of the entry
Return the type of the specified entry in the map
Index of the desired entry
The P4MapApi.Type enumeration for the type of the entry
Adds a new entry in the map
String representing both the the left and right sides of
the new entry
Type of the new entry
Adds a new entry in the map
String representing the the left side of the new entry
String representing the the right side of the new entry
Type of the new entry
Combine two MapApis to create a new MapApi
Pointer to the first map
Pointer to the second map
Combine two MapApis to create a new MapApi
Pointer to the first map
Orientation of the first map
Pointer to the second map
Orientation of the second map
Translate a file path from on side of the mapping to the other
The path to translate
The direction to perform the translation L->R or R->L
Translated path, Null if no translation (path is not mapped)
Free the wrapped native object
The number of entries in the map
Type of the map entry, Include, Exclude, Overlay.
Include the indicated mapping
Exclude the indicated mapping
Overlay the indicated mapping
Specify the direction to perform the mapping.
Map from left to right
Map from right to left
Specifies a fix relationship between one or more jobs and one
or more changelists.
The fix action (Fixed or Unfixed).
Fixed
Fix removed
Describes fields and comments in a Perforce specification.
Set the Values Dictionary from tagged output of a Perforce command.
Needed when the object's data dictionary is set after the object
is created using the default constructer.
Object data
Parse a string specification in the server format into an object.
The base implementation parses the generic specification tag::value
format into the underlying dictionary
String specification
Success/Failure
Create a form specification from the fields that make up a form
Utility function to format a DateTime in the format expected in a spec
Utility to convert a Unix time (Seconds past midnight 1/1/1970) to a DateTime
Utility to convert a Unix time (Seconds past midnight 1/1/1970) to a DateTime
Unix time as a string
Utility to properly format multi-line fields in forms
Multi-line field
Field Data Type for a field in a form specification.
No value.
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.
Bulk: text not indexed for 'p4 jobs -e'
Field Type for a field in a form specification.
The unique identifier for the field.
Required: default provided, value must be present.
Always: always set to the default when saving the form.
Optional: no default, and not required to be present.
Default: default provided, still not required.
Once: set once to the default and never changed.
Specifies structural and semantic metadata for form types.
Create an empty FormSpec
Create a FormSpec
Create a FormSpec from the tagged output of the 'spec' command
Tagged object returned by the 'spec' command
List of all SpecField objects for all fields defined for this Form type.
Map, keyed by SpecField name, containing suitable allowed values for specific form fields.
List of "words" for this form type.
List of "formats" for this form type.
Map, keyed by SpecField name, containing suitable allowed values for specific form fields.
See the main Perforce documentation for formats used here.
Map, keyed by SpecField name, containing preset (default) values for specific form fields.
See the main Perforce documentation for formats used here.
a single (possibly rather long) string (which may contain embedded
newlines) containing comments to be optionally used in GUI or
other representations of the form type.
Class representing a field in a FormSpec.
Create a default FormSpec
Create a FormSpec
Create a SpecField from a 'Fields' entry in the tagged data from the 'spec' command.
Numeric code identifying this form field.
Name of this form field.
A field's type, i.e. whether it's a single word, a date, a selection, or a text field
The maximum length in characters (?) of this field.
Specifies whether the field is optional, required, a key, or set by the server.
A Job in the Repository.
A job specification has only one required field, "Job". If
a Perforce installation uses a complex Job specification than
the simple parsing and string formatting provided by the Form
object cannot properly support the data, the Job object can
subclassed to provide custom parsing and form generation
p4 help job
job -- Create or edit a job (defect) specification
p4 job [-f] [jobName]
p4 job -d jobName
p4 job -o [jobName]
p4 job -i [-f]
The 'p4 job' command 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 associates changelists with jobs.
With no arguments, 'p4 job' creates an empty job specification
and invokes the user's editor. When the specification is saved,
a job name of the form jobNNNNNN is assigned. If the jobName
parameter is specified on the command line, the job is created or
opened for editing.
As jobs are entered or updated, all fields are indexed for searching
Text fields are broken into individual alphanumeric words (punctuation
and whitespace are ignored) and each word is case-folded and entered
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.
The fields that compose a job are defined by the 'p4 jobspec' command.
Perforce provides a default job specification that you can edit.
The -d flag deletes the specified job. You cannot delete a job if
it has pending or submitted fixes associated with it.
The -o flag writes the job specification to the standard output.
The user's editor is not invoked.
The -i flag reads a job specification from the standard input. The
user's editor is not invoked.
The -f flag enables you set fields that are read-only by default.
The -f flag requires 'admin' access, which is granted using the
'p4 protect' command.
Convert to a Job specification
Parse the tagged output of a 'job' command
Parse a Job spec
Convert the Job to a Spec Def
Convert an array of Jobs to a list of JobIds to be passed as
parameters to a command
The job name
A label specification in a Perforce repository.
Read the fields from the tagged output of a label command
Tagged output from the 'label' command
Parse the fields from a label specification
Text of the label specification in server format
Format of a label specification used to save a label to the server
Convert to specification in server format
Read the fields from the tagged output of a labels command
Tagged output from the 'labels' command
A generic list of command options and values.
Options for the resolve command
Options for the stream command
Options for the streams command
Options for the istat command
Options for the branch command
Options for the branches command
Options for the label command
Options for the labels command
Options for the labels command
Options for the diff2 command
Options for GetOpenedFiles
Options for the fstat command
Options for the files command
p4 help files
files -- List files in the depot
p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
p4 files -U unloadfile ...
List details about specified files: depot file name, revision,
file, type, change action and changelist number of the current
head revision. If client syntax is used to specify the file
argument, the client view mapping is used to determine the
corresponding depot files.
By default, the head revision is listed. If the file argument
specifies a revision, then all files at that revision are listed.
If the file argument specifies a revision range, the highest revision
in the range is used for each file. For details about specifying
revisions, see 'p4 help revisions'.
The -a flag displays all revisions within the specific range, rather
than just the highest revision in the range.
The -A flag displays files in archive depots.
The -e flag displays files with an action of anything other than
deleted, purged or archived. Typically this revision is always
available to sync or integrate from.
The -m flag limits files to the first 'max' number of files.
The -U option displays files in the unload depot (see 'p4 help unload'
for more information about the unload depot).
Options for the dirs command
Options for the print command
Options for the filelog command
Options for the annotate command
Options for the fixes command
Options for the grep command
Options for the integrated command
Options for the protects command
Options for the reviews command
Options for the triggers command
Options for the typemap command
Options for the protect command
Options for the counter command
Construct an blank Options object
Options for the Add command.
Flags for the command
Optional changelist for the fies
Optional file type for the files
p4 help add
add -- Open a new file to add it to the depot
p4 add [-c changelist#] [-d -f -n] [-t filetype] file ...
Open a 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. To be added, the file must not
already reside in the depot, or it must be deleted at the current
head revision. Files can be deleted and re-added.
To associate the open files with a specific pending changelist, use
the -c flag; if you omit the -c flag, the open files are associated
with the default changelist. If file is already open, it is moved
into the specified pending changelist. You cannot reopen a file for
add unless it is already open for add.
As a shortcut to reverting and re-adding, you can use the -d
flag to reopen currently-open files for add (downgrade) under
the following circumstances:
A file that is 'opened for edit' and is synced to the head
revision, and the head revision has been deleted (or moved).
A file that is 'opened for move/add' can be downgraded to add,
which is useful when the source of the move has been deleted
or moved. Typically, under these circumstances, your only
alternative is to revert. In this case, breaking the move
connection enables you to preserve any content changes in the
new file and safely revert the source file (of the move).
To specify file type, use the -t flag. By default, 'p4 add'
determines file type using the name-to-type mapping table managed
by 'p4 typemap' and by examining the file's contents and execute
permission bit. If the file type specified by -t or configured in
the typemap table is a partial filetype, the resulting modifier is
applied to the file type that is determined by 'p4 add'. For more
details, see 'p4 help filetypes'.
To add files with filenames that contain wildcard characters, specify
the -f flag. Filenames that contain the special characters '@', '#',
'%' or '*' are reformatted to encode the characters using ASCII
hexadecimal representation. After the files are added, you must
refer to them using the reformatted file name, because Perforce
does not recognize the local filesystem name.
The -n flag displays a preview of the specified add operation without
changing any files or metadata.
Options for the delete command.
p4 help delete
delete -- Open an existing file for deletion from the depot
p4 delete [-c changelist#] [-n -v -k] file ...
Opens a depot file for deletion.
If the file is synced in the client workspace, it is removed. If a
pending changelist number is specified using with the -c flag, the
file is opened for delete in that changelist. Otherwise, it is opened
in the default pending changelist.
Files that are deleted generally do not appear on the have list.
The -n flag displays a preview of the operation without changing any
files or metadata.
The -v flag enables you to delete files that are not synced to the
client workspace.
The -k flag performs the delete on the server without modifying
client files. Use with caution, as an incorrect delete can cause
discrepancies between the state of the client and the corresponding
server metadata.
Options for the edit command
p4 help edit
edit -- Open an existing file for edit
p4 edit [-c changelist#] [-k -n] [-t filetype] file ...
Open an existing file for edit. The server records the fact that
the current user has opened the file in the current workspace, and
changes the file permission from read-only to read/write.
If -c changelist# is included, the file opened in the specified
pending changelist. If changelist number is omitted, the file is
opened in the 'default' changelist.
If -t filetype is specified, the file is assigned that Perforce
filetype. Otherwise, the filetype of the previous revision is reused.
If a partial filetype is specified, it is combined with the current
filetype.For details, see 'p4 help filetypes'.
Using a filetype of 'auto' will cause the filetype to be choosen
as if the file were being added, that is the typemap will be
considered and the file contents may be examined.
The -n flag previews the operation without changing any files or
metadata.
The -k flag updates metadata without transferring files to the
workspace. This option can be used to tell the server that files in
a client workspace are already editable, even if they are not in the
client view. Typically this flag is used to correct the Perforce
server when it is wrong about the state of files in the client
workspace, but incorrect use of this option can result in inaccurate
file status information.
Options for the integrate command.
p4 help integrate
integrate -- Integrate one set of files into another
p4 integrate [options] fromFile[revRange] toFile
p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
options: -c changelist# -d -f -h -i -o -n -m max -t -v
-D<flags> -R<flags>
'p4 integrate' integrates one set of files (the 'source') into
another (the 'target').
(See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
may be easier and more effective for the task at hand.)
Using the client workspace as a staging area, 'p4 integrate' adds and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits integrated files
to the depot. Unresolved files may not be submitted. Integrations
can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display integration history.
When 'p4 integrate' schedules a workspace file to be resolved, it
leaves it read-only. 'p4 resolve' can operate on a read-only file.
For other pre-submit changes, 'p4 edit' must be used to make the
file writable.
Source and target files can be specified either on the 'p4 integrate'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used on
toFile, it refers to source revisions, not to target revisions. For
details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 integrate' use a stream's branch view. (See
'p4 help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit integrated stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -b flag makes 'p4 integrate' use a user-defined branch view.
(See 'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Note that 'p4 integrate' automatically adusts source-to-target
mappings for moved and renamed files. (Adjustment occurs only if
the 'p4 move' command was used to move/rename files.) The scope of
source and target file sets must include both the old-named and the
new-named files for mappings to be adjusted. Moved source files may
cause target files to be scheduled for filename resolves.
The -f flag forces integrate to ignore integration history and treat
all source revisions as unintegrated. It is meant to be used with
revRange to force reintegration of specific, previously integrated
revisions.
The -i flag enables merging between files that have no prior
integration history. By default, 'p4 integrate' requires a prior
integration in order to identify a base for merging. The -i flag
allows the integration, and schedules the target file to be resolved
using the first source revision as the merge base.
The -o flag causes more merge information to be output. For each
target file scheduled to be resolved, the base file revision and the
source file revision are shown. (After running 'p4 integrate', the
same information is available from 'p4 resolve -o'.)
The -R flags modify the way resolves are scheduled:
-Rb Schedules 'branch resolves' instead of branching new
target files automatically.
-Rd Schedules 'delete resolves' instead of deleting
target files automatically.
-Rs Skips cherry-picked revisions already integrated.
This can improve merge results, but can also cause
multiple resolves per file to be scheduled.
The -D flags modify the way deleted files are treated:
-Dt If the target file has been deleted and the source
file has changed, re-branch the source file on top
of the target file instead of scheduling a resolve.
-Ds If the source file has been deleted and the target
file has changed, delete the target file instead of
scheduling a resolve.
-Di If the source file has been deleted and re-added,
probe revisions that precede the deletion to find
unintegrated revisions. By default, 'p4 integrate'
starts probing at the last re-added revision.
The -d flag is a shorthand for all -D flags used together.
The -h flag leaves the target files at the revision currently synced
to the client (the '#have' revision). By default, target files are
automatically synced to the head revision by 'p4 integrate'.
The -t flag propagates source filetypes instead of scheduling
filetype conflicts to be resolved.
The -m flag limits integration to the first 'max' number of files.
The -n flag displays a preview of integration, without actually
doing anything.
If -c changelist# is specified, the files are opened in the
designated numbered pending changelist instead of the 'default'
changelist.
The -v flag causes a 'virtual' integration that does not modify
client workspace files unless target files need to be resolved.
After submitting a virtual integration, 'p4 sync' can be used to
update the workspace.
Options for the labelsync command.
p4 help labelsync
labelsync -- Apply the label to the contents of the client workspace
p4 labelsync [-a -d -n -q] -l label [file[revRange] ...]
Labelsync causes the specified label to reflect the current contents
of the client. It records the revision of each file currently synced.
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.
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 specified, labelsync updates the specified file.
If the file argument includes a revision specification, that revision
is used instead of the revision synced by the client. If the specified
revision is a deleted revision, the label includes that deleted
revision. See 'p4 help revisions' for details about specifying
revisions.
If the file argument includes a revision range specification,
only files selected by the revision range are updated, and the
highest revision in the range is used.
The -a flag adds the specified file to the label.
The -d deletes the specified file from the label, regardless of
revision.
The -n flag previews the operation without altering the label.
Only the owner of a label can run labelsync on that label. A label
that has its Options: field set to 'locked' cannot be updated.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are displayed.
Options for the lock command.
p4 help lock
lock -- Lock an open file to prevent it from being submitted
p4 lock [-c changelist#] [file ...]
The specified files 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, the lock request
is rejected. If no file names are specified, all files in the
specified changelist are locked. If changelist number is omitted,
files in the default changelist are locked.
Options for the move command.
p4 help move
move -- move file(s) from one location to another
rename -- synonym for 'move'
p4 move [-c changelist#] [-f -n -k] [-t filetype] fromFile toFile
Move takes an already opened file and moves it from one client
location to another, reopening it as a pending depot move. When
the file is submitted with 'p4 submit', its depot file is moved
accordingly.
Wildcards in fromFile and toFile must match. The fromFile must be
a file open for add or edit.
'p4 opened' lists pending moves. 'p4 diff' can compare a moved
client file with its depot original, 'p4 sync' can schedule an
update of a moved file, and 'p4 resolve' can resolve the update.
A client file can be moved many times before it is submitted.
Moving a file back to its original location will undo a pending
move, leaving unsubmitted content intact. Using 'p4 revert'
undoes the move and reverts the unsubmitted content.
If -c changelist# is specified, the file is reopened in the
specified pending changelist as well as being moved.
The -f flag forces a move to an existing target file. The file
must be synced and not opened. The originating source file will
no longer be synced to the client.
If -t filetype is specified, the file is assigned that filetype.
If the filetype is a partial filetype, the partial filetype is
combined with the current filetype. See 'p4 help filetypes'.
The -n flag previews the operation without moving files.
The -k flag performs the rename on the server without modifying
client files. Use with caution, as an incorrect move can cause
discrepancies between the state of the client and the corresponding
server metadata.
The 'move' command requires a release 2009.1 or newer client. The
'-f' flag requires a 2010.1 client.
Options for the reopen command.
p4 help reopen
reopen -- Change the filetype of an open file or move it to
another changelist
p4 reopen [-c changelist#] [-t filetype] file ...
Reopen an open file for the current user in order to move it to a
different changelist or change its filetype.
The target changelist must exist; you cannot create a changelist by
reopening a file. To move a file to the default changelist, use
'p4 reopen -c default'.
If -t filetype is specified, the file is assigned that filetype. If
a partial filetype is specified, it is combined with the current
filetype. For details, see 'p4 help filetypes'.
Options for the resolve command
p4 help resolve
resolve -- Resolve integrations and updates to workspace files
p4 resolve [options] [file ...]
options: -A<flags> -a<flags> -d<flags> -f -n -N -o -t -v
-c changelist#
'p4 resolve' resolves changes to files in the client workspace.
'p4 resolve' works only on files that have been scheduled to be
resolved. The commands that can schedule resolves are: 'p4 sync',
'p4 update', 'p4 submit', 'p4 merge', and 'p4 integrate'. Files must
be resolved before they can be submitted.
Resolving involves two sets of files, a source and a target. The
target is a set of depot files that maps to opened files in the
client workspace. When resolving an integration, the source is a
different set of depot files than the target. When resolving an
update, the source is the same set of depot files as the target,
at a different revision.
The 'p4 resolve' file argument specifies the target. If the file
argument is omitted, all unresolved files are resolved.
Resolving can modify workspace files. To back up files, use 'p4
shelve' before using 'p4 resolve'.
The resolve process is a classic three-way merge. The participating
files are referred to as follows:
'yours' The target file open in the client workspace
'theirs' The source file in the depot
'base' The common ancestor; the highest revision of the
source file already accounted for in the target.
'merged' The merged result.
Filenames, filetypes, and text file content can be resolved by
accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
binary file content can be resolved by accepting either 'yours' or
'theirs'.
When resolving integrated changes, 'p4 resolve' distinguishes among
four results: entirely yours, entirely theirs, a pure merge, or an
edited merge. The distinction is recorded when resolved files are
submitted, and will be used by future commands to determine whether
integration is needed.
In all cases, accepting 'yours' leaves the target file in its current
state. The result of accepting 'theirs' is as follows:
Content: The target file content is overwritten.
Branching: A new target is branched.
Deletion: The target file is deleted.
Filename: The target file is moved or renamed.
Filetype: The target file's type is changed.
For each unresolved change, the user is prompted to accept a result.
Content and non-content changes are resolved separately. For content,
'p4 resolve' places the merged result into a temporary file in the
client workspace. If there are any conflicts, the merged file contains
conflict markers that must be removed by the user.
'p4 resolve' displays a count of text diffs and conflicts, and offers
the following prompts:
Accept:
at Keep only changes to their file.
ay Keep only changes to your file.
* am Keep merged file.
* ae Keep merged and edited file.
* a Keep autoselected file.
Diff:
* dt See their changes alone.
* dy See your changes alone.
* dm See merged changes.
d Diff your file against merged file.
Edit:
et Edit their file (read only).
ey Edit your file (read/write).
* e Edit merged file (read/write).
Misc:
* m Run '$P4MERGE base theirs yours merged'.
(Runs '$P4MERGEUNICODE charset base theirs
yours merged' if set and the file is a
unicode file.)
s Skip this file.
h Print this help message.
^C Quit the resolve operation.
Options marked (*) appear only for text files. The suggested action
will be displayed in brackets.
The 'merge' (m) option enables you to invoke your own merge program, if
one is configured using the $P4MERGE environment variable. Four files
are passed to the program: the base, yours, theirs, and the temporary
file. The program is expected to write merge results to the temporary
file.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ab Resolve file branching.
-Ac Resolve file content changes.
-Ad Resolve file deletions.
-Am Resolve moved and renamed files.
-At Resolve filetype changes.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-as 'Safe' resolve; skip files that need merging.
-am Resolve by merging; skip files with conflicts.
-af Force acceptance of merged files with conflicts.
-at Force acceptance of theirs; overwrites yours.
-ay Force acceptance of yours; ignores theirs.
The -as flag causes the workspace file to be replaced with their file
only if theirs has changed and yours has not.
The -am flag causes the workspace file to be replaced with the result
of merging theirs with yours. If the merge detected conflicts, the
file is left untouched and uresolved.
The -af flag causes the workspace file to be replaced with the result
of merging theirs with yours, even if there were conflicts. This can
leave conflict markers in workspace files.
The -at flag resolves all files by copying theirs into yours. It
should be used with care, as it overwrites any changes made to the
file in the client workspace.
The -ay flag resolves all files by accepting yours and ignoring
theirs. It preserves the content of workspace files.
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-db Ingore whitespace changes.
-dw Ingore whitespace altogether.
-dl Ignores line endings.
The -d flags are also passed to the diff options in the 'p4 resolve'
dialog. Additional -d flags that modify the diff output but do not
modify merge behavior include -dn (RCS), -dc (context), -ds (summary),
and -du (unified). Note that 'p4 resolve' uses text from the client
file if the files differ only in whitespace.
The -f flag enables previously resolved content to be resolved again.
By default, after files have been resolved, 'p4 resolve' does not
process them again.
The -n flag previews the operation without altering files.
The -N flag previews the operation with additional information about
any non-content resolve actions that are scheduled.
The -o flag displays the base file name and revision to be used
during the the merge.
The -t flag forces 'p4 resolve' to attempt a textual merge, even for
files with non-text (binary) types.
The -v flag causes 'p4 resolve' to insert markers for all changes,
not just conflicts.
The -c flag limits 'p4 resolve' to the files in changelist#.
Submit command options
p4 help submit
submit -- Submit open files to the depot
p4 submit [-r -s -f option]
p4 submit [-r -s -f option] file
p4 submit [-r -f option] -d description
p4 submit [-r -f option] -d description file
p4 submit [-r -f option] -c changelist#
p4 submit -i [-r -s -f option]
'p4 submit' commits a pending changelist and its files to the depot.
By default, 'p4 submit' attempts to submit all files in the 'default'
changelist. Submit displays a dialog where you enter a description
of the change and, optionally, delete files from the list of files
to be checked in.
To add files to a changelist before submitting, use any of the
commands that open client workspace files: 'p4 add', 'p4 edit',
etc.
If the file parameter is specified, only files in the default
changelist that match the pattern are submitted.
Files in a stream path can be submitted only by client workspaces
dedicated to the stream. See 'p4 help client'.
Before committing a changelist, 'p4 submit' locks all the files being
submitted. If any file cannot be locked or submitted, the files are
left open in a numbered pending changelist. 'p4 opened' shows
unsubmitted files and their changelists.
Submit is atomic: if the operation succeeds, all files are updated
in the depot. If the submit fails, no depot files are updated.
The -c flag submits the specified pending changelist instead of the
default changelist. Additional changelists can be created manually,
using the 'p4 change' command, or automatically as the result of a
failed attempt to submit the default changelist.
The -d flag passes a description into the specified changelist rather
than displaying the changelist dialog for manual editing. This option
is useful for scripting, but does not allow you to add jobs or modify
the default changelist.
The -f flag enables you to override submit options that are configured
for the client that is submitting the changelist. This flag overrides
the -r (reopen)flag, if it is specified. See 'p4 help client' for
details about submit options.
The -i flag reads a changelist specification from the standard input.
The user's editor is not invoked.
The -r flag reopens submitted files in the default changelist after
submission.
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 details.
Resolved command options.
p4 help resolved
resolved -- Show files that have been resolved but not submitted
p4 resolved [-o] [file ...]
'p4 resolved' lists file updates and integrations that have been
resolved but not yet submitted. To see unresolved integrations,
use 'p4 resolve -n'. To see already submitted integrations, use
'p4 integrated'.
If a depot file path is specified, the output lists resolves for
'theirs' files that match the specified path. If a client file
path is specified, the output lists resolves for 'yours' files
that match the specified path.
The -o flag reports the revision used as the base during the
resolve.
Revert command options.
p4 help revert
revert -- Discard changes from an opened file
p4 revert [-a -n -k -c changelist#] file ...
Revert an open file to the revision that was synced from the depot,
discarding any edits or integrations that have been made. You must
explicitly specify the files to be reverted. Files are removed from
the changelist in which they are open. Locked files are unlocked.
The -a flag reverts only files that are open for edit or integrate
and are unchanged or missing. Files with pending integration records
are left open. The file arguments are optional when -a is specified.
The -n flag displays a preview of the operation.
The -k flag marks the file as reverted in server metadata without
altering files in the client workspace.
The -c flag reverts files that are open in the specified changelist.
Shelve command options.
p4 help shelve
shelve -- Store files from a pending changelist into the depot
p4 shelve [files]
p4 shelve -i [-f | -r]
p4 shelve -r -c changelist#
p4 shelve -c changelist# [-f] [file ...]
p4 shelve -d -c changelist# [-f] [file ...]
'p4 shelve' creates, modifies or deletes shelved files in a pending
changelist. Shelved files remain in the depot until they are deleted
(using 'p4 shelve -d') or replaced by subsequent shelve commands.
After 'p4 shelve', the user can revert the files and restore them
later using 'p4 unshelve'. Other users can 'p4 unshelve' the stored
files into their own workspaces.
Files that have been shelved can be accessed by the 'p4 diff',
'p4 diff2', 'p4 files' and 'p4 print' commands using the revision
specification '@=change', where 'change' is the pending changelist
number.
By default, 'p4 shelve' creates a changelist, adds files from the
user's default changelist, then shelves those files in the depot.
The user is presented with a text changelist form displayed using
the editor configured using the $P4EDITOR environment variable.
If a file pattern is specified, 'p4 shelve' shelves the files that
match the pattern.
The -i flag reads the pending changelist specification with shelved
files from the standard input. The user's editor is not invoked.
To modify an existing changelist with shelved files, specify the
changelist number using the -c flag.
The -c flag specifies the pending changelist that contains shelved
files to be created, deleted, or modified. Only the user and client
of the pending changelist can add or modify its shelved files.
The -f (force) flag must be used with the -c or -i flag to overwrite
any existing shelved files in a pending changelist.
The -r flag (used with -c or -i) enables you to replace all shelved
files in that changelist with the files opened in your own workspace
at that changelist number. Only the user and client workspace of the
pending changelist can replace its shelved files.
The -d flag (used with -c) deletes the shelved files in the specified
changelist so that they can no longer be unshelved. By default, only
the user and client of the pending changelist can delete its shelved
files. A user with 'admin' access can delete shelved files by including
the -f flag to force the operation.
Sync command options.
p4 help sync
sync -- Synchronize the client with its view of the depot
flush -- synonym for 'sync -k'
update -- synonym for 'sync -s'
p4 sync [-f -L -n -k -q] [-m max] [file[revRange] ...]
p4 sync [-L -n -q -s] [-m max] [file[revRange] ...]
p4 sync [-L -n -p -q] [-m max] [file[revRange] ...]
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 maps client and depot file names and
locations.
Sync adds files that are in the client view and have not been
retrieved before. Sync deletes previously retrieved files that
are no longer in the client view or have been deleted from the
depot. Sync updates files that are still in the client view and
have been updated in the depot.
By default, sync affects all files in the client workspace. If file
arguments are given, sync limits its operation to those files.
The file arguments can contain wildcards.
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.
If the file argument includes a revision range specification,
only files selected by the revision range are updated, and the
highest revision in the range is used.
Normally, sync does not overwrite workspace files that the user has
manually made writable. Setting the 'clobber' option in the
client specification disables this safety check.
The -f flag forces resynchronization even if the client already
has the file, and overwriting any writable files. This flag doesn't
affect open files.
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
The -n flag previews the operation without updating the workspace.
The -k flag updates server metadata without syncing files. It is
intended to enable you to ensure that the server correctly reflects
the state of files in the workspace while avoiding a large data
transfer. Caution: an erroneous update can cause the server to
incorrectly reflect the state of the workspace.
The -p flag populates the client workspace, but does not update the
server to reflect those updates. Any file that is already synced or
opened will be bypassed with a warning message. This option is very
useful for build clients or when publishing content without the
need to track the state of the client workspace.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are not suppressed.
The -s flag adds a safety check before sending content to the client
workspace. This check uses MD5 digests to compare the content on the
clients workspace against content that was last synced. If the file
has been modified outside of Perforce's control then an error message
is displayed and the file is not overwritten. This check adds some
extra processing which will affect the performance of the operation.
The -m flag limits sync to the first 'max' number of files. This
option is useful in conjunction with tagged output and the '-n'
flag, to preview how many files will be synced without transferring
all the file data.
Unlock command options.
p4 help unlock
unlock -- Release a locked file, leaving it open
p4 unlock [-c changelist#] [-f] [file ...]
'p4 unlock' releases locks on the specified files, which must be
open in the specified pending changelist. If you omit the changelist
number, the default changelist is assumed. If you omit the file name,
all locked files are unlocked.
By default, files can be unlocked only by the changelist owner. The
-f flag enables you to unlock files in changelists owned by other
users. The -f flag requires 'admin' access, which is granted by 'p4
protect'.
Unshelve command options.
p4 help unshelve
unshelve -- Restore shelved files from a pending change into a workspace
p4 unshelve -s changelist# [-f -n] [-c changelist#] [file ...]
'p4 unshelve' retrieves shelved files from the specified pending
changelist, opens them in a pending changelist and copies them
to the invoking user's workspace. Unshelving files from a pending
changelist is restricted by the user's permissions on the files.
A successful unshelve operation places the shelved files on the
user's workspace with the same open action and pending integration
history as if it had originated from that user and client.
Unshelving a file over an already opened file is only permitted
if both shelved file and opened file are opened for 'edit'. After
unshelving, the workspace file is flagged as unresolved, and
'p4 resolve' must be run to resolve the differences between the
shelved file and the workspace file.
The -s flag specifies the number of the pending changelist that
contains the shelved files.
If a file pattern is specified, 'p4 unshelve' unshelves files that
match the pattern.
The -c flag specifies the changelist to which files are unshelved.
By default, 'p4 unshelve' opens shelved files in the default
changelist.
The -f flag forces the clobbering of any writeable but unopened files
that are being unshelved.
The -n flag previews the operation without changing any files or
metadata.
Copy command options.
p4 help copy
copy -- Copy one set of files to another
p4 copy [options] fromFile[rev] toFile
p4 copy [options] -b branch [-r] [toFile[rev] ...]
p4 copy [options] -b branch -s fromFile[rev] [toFile ...]
p4 copy [options] -S stream [-P parent] [-F] [-r] [toFile[rev] ...]
options: -c changelist# -n -v -m max
'p4 copy' copies one set of files (the 'source') into another (the
'target').
Using the client workspace as a staging area, 'p4 copy' makes the
target identical to the source by branching, replacing, or deleting
files. 'p4 submit' submits copied files to the depot. 'p4 revert'
can be used to revert copied files instead of submitting them. The
history of copied files can be shown with 'p4 filelog' or 'p4
integrated'.
Target files that are already identical to the source, or that are
outside of the client view, are not affected by 'p4 copy'. Opened,
non-identical target files cause 'p4 copy' to exit with a warning.
When 'p4 copy' creates or modifies files in the workspace, it leaves
them read-only; 'p4 edit' can make them writable. Files opened by
'p4 copy' do not need to be resolved.
Source and target files (fromFile and toFile) can be specified on
the 'p4 copy' command line or through a branch view. On the command
line, fromFile is the source file set and toFile is the target file
set. With a branch view, one or more toFile arguments can be given
to limit the scope of the target file set.
A revision specifier can be used to select the revision to copy; by
default, the head revision is copied. The revision specifier can be
used on fromFile, or on toFile, but not on both. When used on toFile,
it refers to source revisions, not to target revisions. A range may
not be used as a revision specifier. For revision syntax, see 'p4
help revisions'.
The -S flag makes 'p4 copy' use a stream's branch view. (See 'p4 help
stream'.) The source is the stream itself, and the target is the
stream's parent. With -r, the direction is reversed. -P can be used
to specify a parent stream other than the stream's actual parent.
Note that to submit copied stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -F flag can be used with -S to force copying even though the
stream does not expect a copy to occur in the direction indicated.
Normally 'p4 copy' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -b flag makes 'p4 copy' use a user-defined branch view. (See
'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the user-defined branch view to be
treated as the target, per the branch view mapping. Optional toFile
arguments may be given to further restrict the scope of the target
file set. -r is ignored when -s is used.
The -c changelist# flag opens files in the designated (numbered)
pending changelist instead of the default changelist.
The -n flag displays a preview of the copy, without actually doing
anything.
The -m flag limits the actions to the first 'max' number of files.
The -v flag causes a 'virtual' copy that does not modify client
workspace files. After submitting a virtual integration, 'p4 sync'
can be used to update the workspace.
p4 help merge
merge -- Merge one set of files into another
p4 merge [options] fromFile[revRange] toFile
p4 merge [options] -b branch [-r] [toFile[revRange] ...]
p4 merge [options] -b branch -s fromFile[revRange] [toFile ...]
p4 merge [options] -S stream [-P parent] [-F] [-r] [toFile[revRange] ...]
options: -c changelist# -n -m max
'p4 merge' merges changes from one set of files (the 'source') into
another (the 'target'). It is a simplified form of the 'p4 integrate'
command.
Using the client workspace as a staging area, 'p4 merge' branches and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits merged files to
the depot. Unresolved files may not be submitted. Merged files can
be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display merge history.
When 'p4 merge' schedules a workspace file to be resolved, it leaves
it read-only. 'p4 resolve' can operate on a read-only file; for
other pre-submit changes, 'p4 edit' must be used to make the file
writable.
Source and target files can be specified either on the 'p4 merge'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
Each file in the target is mapped to a file in the source. Mapping
adjusts automatically for files that have been moved or renamed, as
long as 'p4 move' was used to move/rename files. The scope of source
and target file sets must include both old-named and new-named files
for mappings to be adjusted. Moved source files may schedule moves
to be resolved in target files.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used
on toFile, it refers to source revisions, not to target revisions.
For details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 merge' use a stream's branch view. (See 'p4
help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit merged stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -F flag can be used with -S to force merging even though the
stream does not expect a merge to occur in the direction indicated.
Normally 'p4 merge' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -b flag makes 'p4 merge' use a user-defined branch view. (See
'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Fix command options.
p4 help fix
fix -- Mark jobs as being fixed by the specified changelist
p4 fix [-d] [-s status] -c changelist# jobName ...
'p4 fix' marks each named job as being fixed by the changelist
number specified with -c. The changelist can be pending or
submitted and the jobs can open or closed (fixed by another
changelist).
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 is closed when the
changelist is submitted. If the job is already closed, it remains
closed.
The -d flag deletes the specified fixes. This operation does not
otherwise affect the specified changelist or jobs.
The -s flag uses the specified status instead of the default defined
in the job specification. This status is reported by 'p4 fixes'.
The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit'
(of a pending changelist) commands set the job's status to the fix's
status for each job associated with the change. If the fix's status
is 'same', the job's status is left unchanged.
User command options.
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
Users command options.
p4 help users
users -- List Perforce users
p4 users [-l -a -r -c] [-m max] [user ...]
Lists all Perforce users or users that match the 'user' argument.
The report includes the last time that each user accessed the system.
The -m max flag limits output to the first 'max' number of users.
The -a flag includes service and operator users in the output.
The -l flag includes additional information in the output. The -l
flag requires 'super' access, which is granted by 'p4 protect'.
The -r and -c flags are only allowed on replica servers. When
-r is given only users who have used a replica are reported and
when -c is given only the user information from the central server
is reported. Otherwise on a replica server, the user list will
be slightly different from the master server as the user access times
will reflect replica usage or master usage whichever is newer.
Client command options.
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [-f] name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
Client command options.
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [-f] name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
Clients command options.
p4 help clients
clients -- Display list of clients
workspaces -- synonym for 'clients'
p4 clients [-t] [-u user] [[-e|-E] nameFilter -m max] [-S stream]
Lists all client workspaces currently defined in the server.
The -t flag displays the time as well as the date.
The -u user flag lists client workspaces that are owned by the
specified user.
The -e nameFilter flag lists workspaces with a name that matches
the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes
the matching case-insensitive.
The -m max flag limits output to the specified number of workspaces.
The -S stream flag limits output to the client workspaces dedicated
to the stream.
Change command options.
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [changelist#]
p4 change -d [-f -s] changelist#
p4 change -o [-s] [-f] [changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-f | -u] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. The -f flag requires 'admin' access granted by 'p4
protect'. The -f and -u flags are mutually exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
Change command options.
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [changelist#]
p4 change -d [-f -s] changelist#
p4 change -o [-s] [-f] [changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-f | -u] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. The -f flag requires 'admin' access granted by 'p4
protect'. The -f and -u flags are mutually exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
Changes command options.
p4 help changes
changes -- Display list of pending and submitted changelists
changelists -- synonym for 'changes'
p4 changes [options] [file[revRange] ...]
options: -i -t -l -L -f -c client -m max -s status -u user
Returns a list of all pending and submitted changelists currently
stored in the server.
If files are specified, 'p4 changes' lists only changelists that
affect those files. If the file specification includes a revision
range, 'p4 changes' lists only submitted changelists that affect
the specified revisions. See 'p4 help revisions' for details.
If files are not specified, 'p4 changes' limits its report
according to each change's type ('public' or 'restricted').
If a submitted or shelved change is restricted, the change is
not reported unless the user owns the change or has list
permission for at least one file in the change. Only the owner
of a restricted and pending (not shelved) change is permitted
to see it.
The -i flag also includes any changelists integrated into the
specified files.
The -t flag displays the time as well as the date.
The -l flag displays the full text of the changelist
descriptions.
The -L flag displays the changelist descriptions, truncated to 250
characters if longer.
The -f flag enables admin users to view restricted changes.
The -c client flag displays only submitted by the specified client.
The -m max flag limits changes to the 'max' most recent.
The -s status flag limits the output to pending, shelved or
submitted changelists.
The -u user flag displays only changes owned by the specified user.
Group command options.
p4 help group
group -- Change members of user group
p4 group [-a] name
p4 group -d [-a] name
p4 group -o name
p4 group -i [-a]
Create a group or modify the membership of an existing group.
A group can contain users and other groups. The group specification
is put into a temporary file and the editor (configured by the
environment variable $P4EDITOR) is invoked.
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.
Each group has MaxResults, MaxScanRows, and MaxLockTime fields,
which limit the resources committed to operations performed by
members of the group. For these fields, 'unlimited' or 'unset'
means no limit for that group. An individual user's limit is the
highest of any group with a limit to which he belongs, unlimited if
any of his groups has 'unlimited' for that field, or unlimited
if he belongs to no group with a limit. See 'p4 help maxresults'
for more information on MaxResults, MaxScanRows and MaxLockTime.
Each group also has a Timeout field, which specifies how long (in
seconds) a 'p4 login' ticket remains valid. A value of 'unset' or
'unlimited' is equivalent to no timeout. An individual's timeout is
the highest of any group with a limit to which he belongs, unlimited
if any of his groups has 'unlimited' for the timeout value, or
unlimited if he belongs to no group with a limit. See 'p4 help login'
for more information.
Each group has a PasswordTimeout field, which determines how long a
password remains valid for members of the group.
The -d flag deletes a group.
The -o flag writes the group specification to standard output. The
user's editor is not invoked.
The -i flag reads a group specification from standard input. The
user's editor is not invoked. The new group specification replaces
the previous one.
The -a flag enables a user without 'super' access to modify the group
if that user is an 'owner' of that group. Group owners are specified
in the 'Owners' field of the group spec.
The -A flag enables a user with 'admin' access to add a new group.
Existing groups may not be modified when this flag is used.
All commands that require access granted by 'p4 protect' consider a
user's groups when calculating access levels.
'p4 group' requires 'super' access granted by 'p4 protect' unless
invoked with the '-a' flag by a qualified user.
Groups command options.
p4 help groups
groups -- List groups (of users)
p4 groups [-m max] [[[-i] user | group] | [-v [group]]]
List all user groups defined in the server. If a user argument is,
specified, only groups containing that user are displayed. If a group
argument is specified, only groups containing the group are displayed.
The -i flag also displays groups that the user or group belongs to
indirectly by means of membership in subgroups.
The -m max flag limits output to the specified number of groups.
The -v flag displays the MaxResults, MaxScanRows, MaxLockTime, and
Timeout values for the specified group.
Options for job command.
p4 help job
job -- Create or edit a job (defect) specification
p4 job [-f] [jobName]
p4 job -d jobName
p4 job -o [jobName]
p4 job -i [-f]
The 'p4 job' command 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 associates changelists with jobs.
With no arguments, 'p4 job' creates an empty job specification
and invokes the user's editor. When the specification is saved,
a job name of the form jobNNNNNN is assigned. If the jobName
parameter is specified on the command line, the job is created or
opened for editing.
As jobs are entered or updated, all fields are indexed for searching
Text fields are broken into individual alphanumeric words (punctuation
and whitespace are ignored) and each word is case-folded and entered
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.
The fields that compose a job are defined by the 'p4 jobspec' command.
Perforce provides a default job specification that you can edit.
The -d flag deletes the specified job. You cannot delete a job if
it has pending or submitted fixes associated with it.
The -o flag writes the job specification to the standard output.
The user's editor is not invoked.
The -i flag reads a job specification from the standard input. The
user's editor is not invoked.
The -f flag enables you set fields that are read-only by default.
The -f flag requires 'admin' access, which is granted using the
'p4 protect' command.
Jobs command options.
p4 help jobs
jobs -- Display list of jobs
p4 jobs [-e jobview -i -l -m max -r] [file[revRange] ...]
p4 jobs -R
Lists jobs in the server. If a file specification is included, fixes
for submitted changelists affecting the specified files are listed.
The file specification can include wildcards and a revision range.
See 'p4 help revisions' for details about specifying revisions.
The -e flag lists jobs matching the expression specified in the
jobview parameter. For a description of jobview syntax, see 'p4 help
jobview'.
The -i flag includes any fixes made by changelists integrated into
the specified files.
The -l flag produces long output with the full text of the job
descriptions.
The -m max flag limits the output to the first 'max' jobs, ordered
by their job name.
The -r flag sorts the jobs in reverse order (by job name).
The -R flag rebuilds the jobs table and reindexes each job, which
is necessary after upgrading to 98.2. 'p4 jobs -R' requires that
that the user be an operator or have 'super' access granted by
'p4 protect'.
Options for the files command.
p4 help Files
Options for the filelog command.
Options for the login command.
Options for the logout command.
Options for the tag command.
Options for GetOpenedFiles
p4 help opened
opened -- List open files and display file status
p4 opened [-a -c changelist# -C client -u user -m max -s] [file ...]
p4 opened [-a -x -m max ] [file ...]
Lists files currently opened in pending changelists, or, for
specified files, show whether they are currently opened or locked.
If the file specification is omitted, all files open in the current
client workspace are listed.
Files in shelved changelists are not displayed by this command. To
display shelved changelists, see 'p4 changes -s shelved'; to display
the files in those shelved changelists, see 'p4 describe -s -S'.
The -a flag lists opened files in all clients. By default, only
files opened by the current client are listed.
The -c changelist# flag lists files opened in the specified
changelist#.
The -C client flag lists files open in the specified client workspace.
The -u user flag lists files opened by the specified user.
The -m max flag limits output to the first 'max' number of files.
The -s option produces 'short' and optimized output when used with
the -a (all clients) option. For large repositories '-a' can take
a long time when compared to '-as'.
The -x option lists files that are opened 'exclusive'. This option
only applies to a distributed installation where global tracking of
these file types is necessary across servers. The -x option implies
the -a option.
Command options for GetFileContentsCmd()
p4 help print
print -- Write a depot file to standard output
p4 print [-a -o localFile -q] file[revRange] ...
Retrieve the contents of a depot file to the client's standard output.
The file is not synced. If file is specified using client syntax,
Perforce uses the client view to determine the corresponding depot
file.
By default, the head revision is printed. If the file argument
includes a revision, the specified revision is 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 printed. For details about revision specifiers, see 'p4
help revisions'.
The -a flag prints all revisions within the specified range, rather
than just the highest revision in the range.
The -o localFile flag redirects the output to the specified file on
the client filesystem.
The -q flag suppresses the initial line that displays the file name
and revision.
Options for the Describe command
p4 help describe
describe -- Display a changelist description
p4 describe [-d<flags> -s -S -f] changelist# ...
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 indicated as 'pending' and file diffs are not displayed.
For restricted changelists, 'no permission' is displayed if the user
is not permitted to view the change (see 'p4 help change'). If a
submitted or shelved change is restricted, the description is hidden
unless the user is the owner of the change or has list permission for
at least one file in the change. To view restricted pending (not
shelved) changes, the user must be the owner of the change.
The -d<flags> passes one or more flags to the built-in diff routine
to modify the output: -dn (RCS), -dc[n] (context), -ds (summary),
-du[n] (unified), -db (ignore whitespace changes), -dw (ignore
whitespace), -dl (ignore line endings). The optional argument to
to -dc specifies number of context lines.
The -s flag omits the diffs of files that were updated.
The -S flag lists files that are shelved for the specified changelist
and displays diffs of the files against their previous revision.
The -f flag forces display of the descriptions in a restricted
change. The -f flag requires 'admin' access, which is granted
using 'p4 protect'.
Options for the trust command
p4 trust -h
trust -- Establish trust of an SSL connection
p4 trust [ -l -y -n -d -f -r -i <fingerprint> ]
Establish trust of an SSL connection. This client command manages
the p4 trust file. This file contains fingerprints of the keys
received on ssl connections. When an SSL connection is made, this
file is examined to determine if the SSL connection has been used
before and if the key is the same as a previously seen key for that
connection. Establishing trust with a connection prevents undetected
communication interception (man-in-the-middle) attacks.
Most options are mutually exclusive. Only the -r and -f options
can be combined with the others.
The -l flag lists existing known fingerprints.
Without options, this command will make a connection to a server
and examine the key if present, if one cannot be found this command
will show a fingerprint and ask if this connection should be trusted.
If a fingerprint exists and does not match, an error that a possible
security problems exists will be displayed.
The -y flag will cause prompts to be automatically accepted.
The -n flag will cause prompts to be automatically refused.
The -d flag will remove an existing trusted fingerprint of a connection.
The -f flag will force the replacement of a mismatched fingerprint.
The -i flag will allow a specific fingerprint to be installed.
The -r flag specifies that a replacement fingerprint is to be
affected. Replacement fingerprints can be used in anticipation
of a server replacing its key. If a replacement fingerprint
exists for a connection and the primary fingerprint does not match
while the replacement fingerprint does, the replacement fingerprint
will replace the primary. This flag can be combined with -l, -i,
or -d.
Options for the trust command
p4 help info
info -- Display client/server information
p4 info [-s]
Info lists information about the current client (user name,
client name, applicable client root, client current directory,
and the client IP address) and some server information (server
IP address, server root, date, uptime, version and license data).
The -s option produces 'short' output that omits any information
that requires a database lookup such as the client root).
Flags for the add command.
No flags.
As a shortcut to reverting and re-adding, you can use the -d
flag to reopen currently-open files for add (downgrade) under
the following circumstances:
A file that is 'opened for edit' and is synced to the head
revision, and the head revision has been deleted (or moved).
A file that is 'opened for move/add' can be downgraded to add,
which is useful when the source of the move has been deleted
or moved. Typically, under these circumstances, your only
alternative is to revert. In this case, breaking the move
connection enables you to preserve any content changes in the
new file and safely revert the source file (of the move).
To add files with filenames that contain wildcard characters, specify
the -f flag. Filenames that contain the special characters '@', '#',
'%' or '*' are reformatted to encode the characters using ASCII
hexadecimal representation.
The -I flag informs the client that it should not perform any ignore
checking configured by P4IGNORE.
The -n flag, displays a preview of the specified add operation without
changing any files or metadata.
Add command options
Options for the Add command.
Flags for the command
Optional changelist for the fies
Optional file type for the files
p4 help add
add -- Open a new file to add it to the depot
p4 add [-c changelist#] [-d -f -n] [-t filetype] file ...
Open a 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. To be added, the file must not
already reside in the depot, or it must be deleted at the current
head revision. Files can be deleted and re-added.
To associate the open files with a specific pending changelist, use
the -c flag; if you omit the -c flag, the open files are associated
with the default changelist. If file is already open, it is moved
into the specified pending changelist. You cannot reopen a file for
add unless it is already open for add.
As a shortcut to reverting and re-adding, you can use the -d
flag to reopen currently-open files for add (downgrade) under
the following circumstances:
A file that is 'opened for edit' and is synced to the head
revision, and the head revision has been deleted (or moved).
A file that is 'opened for move/add' can be downgraded to add,
which is useful when the source of the move has been deleted
or moved. Typically, under these circumstances, your only
alternative is to revert. In this case, breaking the move
connection enables you to preserve any content changes in the
new file and safely revert the source file (of the move).
To specify file type, use the -t flag. By default, 'p4 add'
determines file type using the name-to-type mapping table managed
by 'p4 typemap' and by examining the file's contents and execute
permission bit. If the file type specified by -t or configured in
the typemap table is a partial filetype, the resulting modifier is
applied to the file type that is determined by 'p4 add'. For more
details, see 'p4 help filetypes'.
To add files with filenames that contain wildcard characters, specify
the -f flag. Filenames that contain the special characters '@', '#',
'%' or '*' are reformatted to encode the characters using ASCII
hexadecimal representation. After the files are added, you must
refer to them using the reformatted file name, because Perforce
does not recognize the local filesystem name.
The -n flag displays a preview of the specified add operation without
changing any files or metadata.
Flags for the delete command.
No flags.
The -n flag, displays a preview of the operation without changing any
files or metadata.
The -v flag, enables you to delete files that are not synced to the
client workspace.
The -k flag performs the delete on the server without modifying
client files. Use with caution, as an incorrect delete can cause
discrepancies between the state of the client and the corresponding
server metadata.
delete command options
Options for the delete command.
p4 help delete
delete -- Open an existing file for deletion from the depot
p4 delete [-c changelist#] [-n -v -k] file ...
Opens a depot file for deletion.
If the file is synced in the client workspace, it is removed. If a
pending changelist number is specified using with the -c flag, the
file is opened for delete in that changelist. Otherwise, it is opened
in the default pending changelist.
Files that are deleted generally do not appear on the have list.
The -n flag displays a preview of the operation without changing any
files or metadata.
The -v flag enables you to delete files that are not synced to the
client workspace.
The -k flag performs the delete on the server without modifying
client files. Use with caution, as an incorrect delete can cause
discrepancies between the state of the client and the corresponding
server metadata.
Flags for the edit command.
No flags.
The -n flag, previews the operation without changing any files or
metadata.
The -k flag, updates metadata without transferring files to the
workspace.
Options for the edit command
Options for the edit command
p4 help edit
edit -- Open an existing file for edit
p4 edit [-c changelist#] [-k -n] [-t filetype] file ...
Open an existing file for edit. The server records the fact that
the current user has opened the file in the current workspace, and
changes the file permission from read-only to read/write.
If -c changelist# is included, the file opened in the specified
pending changelist. If changelist number is omitted, the file is
opened in the 'default' changelist.
If -t filetype is specified, the file is assigned that Perforce
filetype. Otherwise, the filetype of the previous revision is reused.
If a partial filetype is specified, it is combined with the current
filetype.For details, see 'p4 help filetypes'.
Using a filetype of 'auto' will cause the filetype to be choosen
as if the file were being added, that is the typemap will be
considered and the file contents may be examined.
The -n flag previews the operation without changing any files or
metadata.
The -k flag updates metadata without transferring files to the
workspace. This option can be used to tell the server that files in
a client workspace are already editable, even if they are not in the
client view. Typically this flag is used to correct the Perforce
server when it is wrong about the state of files in the client
workspace, but incorrect use of this option can result in inaccurate
file status information.
Flags for the integrate command.
No flags.
-Dt If the target file has been deleted and the source
file has changed, re-branch the source file on top
of the target file.
-Ds If the source file has been deleted and the target
file has changed, delete the target file.
-Di If the source file has been deleted and re-added,
attempt to integrate all outstanding revisions
of the file, including revisions prior to the
delete. By default, 'p4 integrate' only considers
revisions since the last add.
The -h flag leaves the target files at the revision currently synced
to the client (the '#have' revision). By default, target files are
automatically synced to the head revision by 'p4 integrate'.
The -o flag displays the base file name and revision that will be
used in subsequent resolves if a resolve is needed.
The -n flag displays a preview of required integrations.
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.
The -v flag speeds integration by not syncing newly-branched files to
the client. The files can be synced after they are submitted.
-Rb Schedules 'branch resolves' instead of branching new
target files automatically.
-Rd Schedules 'delete resolves' instead of deleting
target files automatically.
-Rs Skips cherry-picked revisions already integrated.
This can improve merge results, but can also cause
multiple resolves per file to be scheduled.
Integrate command options
Options for the integrate command.
p4 help integrate
integrate -- Integrate one set of files into another
p4 integrate [options] fromFile[revRange] toFile
p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
options: -c changelist# -d -f -h -i -o -n -m max -t -v
-D<flags> -R<flags>
'p4 integrate' integrates one set of files (the 'source') into
another (the 'target').
(See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
may be easier and more effective for the task at hand.)
Using the client workspace as a staging area, 'p4 integrate' adds and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits integrated files
to the depot. Unresolved files may not be submitted. Integrations
can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display integration history.
When 'p4 integrate' schedules a workspace file to be resolved, it
leaves it read-only. 'p4 resolve' can operate on a read-only file.
For other pre-submit changes, 'p4 edit' must be used to make the
file writable.
Source and target files can be specified either on the 'p4 integrate'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used on
toFile, it refers to source revisions, not to target revisions. For
details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 integrate' use a stream's branch view. (See
'p4 help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit integrated stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -b flag makes 'p4 integrate' use a user-defined branch view.
(See 'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Note that 'p4 integrate' automatically adusts source-to-target
mappings for moved and renamed files. (Adjustment occurs only if
the 'p4 move' command was used to move/rename files.) The scope of
source and target file sets must include both the old-named and the
new-named files for mappings to be adjusted. Moved source files may
cause target files to be scheduled for filename resolves.
The -f flag forces integrate to ignore integration history and treat
all source revisions as unintegrated. It is meant to be used with
revRange to force reintegration of specific, previously integrated
revisions.
The -i flag enables merging between files that have no prior
integration history. By default, 'p4 integrate' requires a prior
integration in order to identify a base for merging. The -i flag
allows the integration, and schedules the target file to be resolved
using the first source revision as the merge base.
The -o flag causes more merge information to be output. For each
target file scheduled to be resolved, the base file revision and the
source file revision are shown. (After running 'p4 integrate', the
same information is available from 'p4 resolve -o'.)
The -R flags modify the way resolves are scheduled:
-Rb Schedules 'branch resolves' instead of branching new
target files automatically.
-Rd Schedules 'delete resolves' instead of deleting
target files automatically.
-Rs Skips cherry-picked revisions already integrated.
This can improve merge results, but can also cause
multiple resolves per file to be scheduled.
The -D flags modify the way deleted files are treated:
-Dt If the target file has been deleted and the source
file has changed, re-branch the source file on top
of the target file instead of scheduling a resolve.
-Ds If the source file has been deleted and the target
file has changed, delete the target file instead of
scheduling a resolve.
-Di If the source file has been deleted and re-added,
probe revisions that precede the deletion to find
unintegrated revisions. By default, 'p4 integrate'
starts probing at the last re-added revision.
The -d flag is a shorthand for all -D flags used together.
The -h flag leaves the target files at the revision currently synced
to the client (the '#have' revision). By default, target files are
automatically synced to the head revision by 'p4 integrate'.
The -t flag propagates source filetypes instead of scheduling
filetype conflicts to be resolved.
The -m flag limits integration to the first 'max' number of files.
The -n flag displays a preview of integration, without actually
doing anything.
If -c changelist# is specified, the files are opened in the
designated numbered pending changelist instead of the 'default'
changelist.
The -v flag causes a 'virtual' integration that does not modify
client workspace files unless target files need to be resolved.
After submitting a virtual integration, 'p4 sync' can be used to
update the workspace.
Flags for the label sync command.
No flags.
The -a flag adds the specified file to the label.
The -d deletes the specified file from the label, regardless of
revision.
The -n flag previews the operation without altering the label.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are displayed.
Labelsync command options
Options for the labelsync command.
p4 help labelsync
labelsync -- Apply the label to the contents of the client workspace
p4 labelsync [-a -d -n -q] -l label [file[revRange] ...]
Labelsync causes the specified label to reflect the current contents
of the client. It records the revision of each file currently synced.
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.
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 specified, labelsync updates the specified file.
If the file argument includes a revision specification, that revision
is used instead of the revision synced by the client. If the specified
revision is a deleted revision, the label includes that deleted
revision. See 'p4 help revisions' for details about specifying
revisions.
If the file argument includes a revision range specification,
only files selected by the revision range are updated, and the
highest revision in the range is used.
The -a flag adds the specified file to the label.
The -d deletes the specified file from the label, regardless of
revision.
The -n flag previews the operation without altering the label.
Only the owner of a label can run labelsync on that label. A label
that has its Options: field set to 'locked' cannot be updated.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are displayed.
Lock command options
Options for the lock command.
p4 help lock
lock -- Lock an open file to prevent it from being submitted
p4 lock [-c changelist#] [file ...]
The specified files 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, the lock request
is rejected. If no file names are specified, all files in the
specified changelist are locked. If changelist number is omitted,
files in the default changelist are locked.
Flags for the move command.
No flags.
The -f flag forces a move to an existing target file. The file
must be synced and not opened. The originating source file will
no longer be synced to the client.
The -n flag previews the operation without moving files.
The -k flag performs the rename on the server without modifying
client files. Use with caution, as an incorrect move can cause
discrepancies between the state of the client and the corresponding
server metadata.
Move command options
Options for the move command.
p4 help move
move -- move file(s) from one location to another
rename -- synonym for 'move'
p4 move [-c changelist#] [-f -n -k] [-t filetype] fromFile toFile
Move takes an already opened file and moves it from one client
location to another, reopening it as a pending depot move. When
the file is submitted with 'p4 submit', its depot file is moved
accordingly.
Wildcards in fromFile and toFile must match. The fromFile must be
a file open for add or edit.
'p4 opened' lists pending moves. 'p4 diff' can compare a moved
client file with its depot original, 'p4 sync' can schedule an
update of a moved file, and 'p4 resolve' can resolve the update.
A client file can be moved many times before it is submitted.
Moving a file back to its original location will undo a pending
move, leaving unsubmitted content intact. Using 'p4 revert'
undoes the move and reverts the unsubmitted content.
If -c changelist# is specified, the file is reopened in the
specified pending changelist as well as being moved.
The -f flag forces a move to an existing target file. The file
must be synced and not opened. The originating source file will
no longer be synced to the client.
If -t filetype is specified, the file is assigned that filetype.
If the filetype is a partial filetype, the partial filetype is
combined with the current filetype. See 'p4 help filetypes'.
The -n flag previews the operation without moving files.
The -k flag performs the rename on the server without modifying
client files. Use with caution, as an incorrect move can cause
discrepancies between the state of the client and the corresponding
server metadata.
The 'move' command requires a release 2009.1 or newer client. The
'-f' flag requires a 2010.1 client.
Options for the reopen command.
Options for the reopen command.
p4 help reopen
reopen -- Change the filetype of an open file or move it to
another changelist
p4 reopen [-c changelist#] [-t filetype] file ...
Reopen an open file for the current user in order to move it to a
different changelist or change its filetype.
The target changelist must exist; you cannot create a changelist by
reopening a file. To move a file to the default changelist, use
'p4 reopen -c default'.
If -t filetype is specified, the file is assigned that filetype. If
a partial filetype is specified, it is combined with the current
filetype. For details, see 'p4 help filetypes'.
Flags for the resolve command.
No flags.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Aa Resolve attributes.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ab Resolve file branching.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ac Resolve file content changes.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ad Resolve file deletions.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Am Resolve moved and renamed files.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-At Resolve filetype changes.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-as 'Safe' resolve; skip files that need merging.
The -as flag causes the workspace file to be replaced with their file
only if theirs has changed and yours has not.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-am Resolve by merging; skip files with conflicts.
The -am flag causes the workspace file to be replaced with the result
of merging theirs with yours. If the merge detected conflicts, the
file is left untouched and unresolved.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-af Force acceptance of merged files with conflicts.
The -af flag causes the workspace file to be replaced with the result
of merging theirs with yours, even if there were conflicts. This can
leave conflict markers in workspace files.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-at Force acceptance of theirs; overwrites yours.
The -at flag resolves all files by copying theirs into yours. It
should be used with care, as it overwrites any changes made to the
file in the client workspace.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-ay Force acceptance of yours; ignores theirs.
The -ay flag resolves all files by accepting yours and ignoring
theirs. It preserves the content of workspace files.
The -f flag enables previously resolved files to be resolved again.
By default, after files have been resolved, 'p4 resolve' does not
process them again.
The -n flag previews the operation without altering files.
The -N flag previews the operation with additional information about
any non-content resolve actions that are scheduled.
The -o flag displays the base file name and revision to be used
during the the merge.
The -t flag forces 'p4 resolve' to attempt a textual merge, even for
files with non-text (binary) types.
The -v flag causes 'p4 resolve' to insert markers for all changes,
not just conflicts.
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-db Ignore Whitespace Changes
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-dw Ingore whitespace altogether.
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-dl Ignore Line Endings
Options for the resolve command.
Options for the resolve command.
p4 help resolve
resolve -- Resolve integrations and updates to workspace files
p4 resolve [options] [file ...]
options: -A<flags> -a<flags> -d<flags> -f -n -N -o -t -v
-c changelist#
'p4 resolve' resolves changes to files in the client workspace.
'p4 resolve' works only on files that have been scheduled to be
resolved. The commands that can schedule resolves are: 'p4 sync',
'p4 update', 'p4 submit', 'p4 merge', and 'p4 integrate'. Files must
be resolved before they can be submitted.
Resolving involves two sets of files, a source and a target. The
target is a set of depot files that maps to opened files in the
client workspace. When resolving an integration, the source is a
different set of depot files than the target. When resolving an
update, the source is the same set of depot files as the target,
at a different revision.
The 'p4 resolve' file argument specifies the target. If the file
argument is omitted, all unresolved files are resolved.
Resolving can modify workspace files. To back up files, use 'p4
shelve' before using 'p4 resolve'.
The resolve process is a classic three-way merge. The participating
files are referred to as follows:
'yours' The target file open in the client workspace
'theirs' The source file in the depot
'base' The common ancestor; the highest revision of the
source file already accounted for in the target.
'merged' The merged result.
Filenames, filetypes, and text file content can be resolved by
accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
binary file content can be resolved by accepting either 'yours' or
'theirs'.
When resolving integrated changes, 'p4 resolve' distinguishes among
four results: entirely yours, entirely theirs, a pure merge, or an
edited merge. The distinction is recorded when resolved files are
submitted, and will be used by future commands to determine whether
integration is needed.
In all cases, accepting 'yours' leaves the target file in its current
state. The result of accepting 'theirs' is as follows:
Content: The target file content is overwritten.
Branching: A new target is branched.
Deletion: The target file is deleted.
Filename: The target file is moved or renamed.
Filetype: The target file's type is changed.
For each unresolved change, the user is prompted to accept a result.
Content and non-content changes are resolved separately. For content,
'p4 resolve' places the merged result into a temporary file in the
client workspace. If there are any conflicts, the merged file contains
conflict markers that must be removed by the user.
'p4 resolve' displays a count of text diffs and conflicts, and offers
the following prompts:
Accept:
at Keep only changes to their file.
ay Keep only changes to your file.
* am Keep merged file.
* ae Keep merged and edited file.
* a Keep autoselected file.
Diff:
* dt See their changes alone.
* dy See your changes alone.
* dm See merged changes.
d Diff your file against merged file.
Edit:
et Edit their file (read only).
ey Edit your file (read/write).
* e Edit merged file (read/write).
Misc:
* m Run '$P4MERGE base theirs yours merged'.
(Runs '$P4MERGEUNICODE charset base theirs
yours merged' if set and the file is a
unicode file.)
s Skip this file.
h Print this help message.
^C Quit the resolve operation.
Options marked (*) appear only for text files. The suggested action
will be displayed in brackets.
The 'merge' (m) option enables you to invoke your own merge program, if
one is configured using the $P4MERGE environment variable. Four files
are passed to the program: the base, yours, theirs, and the temporary
file. The program is expected to write merge results to the temporary
file.
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ab Resolve file branching.
-Ac Resolve file content changes.
-Ad Resolve file deletions.
-Am Resolve moved and renamed files.
-At Resolve filetype changes.
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-as 'Safe' resolve; skip files that need merging.
-am Resolve by merging; skip files with conflicts.
-af Force acceptance of merged files with conflicts.
-at Force acceptance of theirs; overwrites yours.
-ay Force acceptance of yours; ignores theirs.
The -as flag causes the workspace file to be replaced with their file
only if theirs has changed and yours has not.
The -am flag causes the workspace file to be replaced with the result
of merging theirs with yours. If the merge detected conflicts, the
file is left untouched and uresolved.
The -af flag causes the workspace file to be replaced with the result
of merging theirs with yours, even if there were conflicts. This can
leave conflict markers in workspace files.
The -at flag resolves all files by copying theirs into yours. It
should be used with care, as it overwrites any changes made to the
file in the client workspace.
The -ay flag resolves all files by accepting yours and ignoring
theirs. It preserves the content of workspace files.
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-db Ingore whitespace changes.
-dw Ingore whitespace altogether.
-dl Ignores line endings.
The -d flags are also passed to the diff options in the 'p4 resolve'
dialog. Additional -d flags that modify the diff output but do not
modify merge behavior include -dn (RCS), -dc (context), -ds (summary),
and -du (unified). Note that 'p4 resolve' uses text from the client
file if the files differ only in whitespace.
The -f flag enables previously resolved content to be resolved again.
By default, after files have been resolved, 'p4 resolve' does not
process them again.
The -n flag previews the operation without altering files.
The -N flag previews the operation with additional information about
any non-content resolve actions that are scheduled.
The -o flag displays the base file name and revision to be used
during the the merge.
The -t flag forces 'p4 resolve' to attempt a textual merge, even for
files with non-text (binary) types.
The -v flag causes 'p4 resolve' to insert markers for all changes,
not just conflicts.
The -c flag limits 'p4 resolve' to the files in changelist#.
Diff whitespace options flags.
None
-db Ignore Whitespace Changes
-dw Ingore whitespace altogether.
-dl Ignore Line Endings
-dn RCS
-dc[n] Show context of changes
-ds Summary
-du[n] Unified
Flags for the submit command.
No flags.
The -r flag reopens submitted files in the default changelist after
submission.
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 details.
submission.
The -e flag submits a shelved changelist without transferring files
or modifying the workspace. The shelved change must be owned by
the person submitting the change, but the client may be different.
However, files shelved to a stream target may only be submitted by
a stream client that is mapped to the target stream. In addition,
files shelved to a non-stream target cannot be submitted by a
stream client. Submitting shelved changes by a task stream
client is not supported. To submit a shelved change, all
files in the shelved change must be up to date and resolved. No
files may be open in any workspace at the same change number.
Client submit options (ie revertUnchanged, etc) will be ignored.
If the submit is successful, the shelved change and files
are cleaned up, and are no longer available to be unshelved or
submitted.
Submit command options
Submit command options
p4 help submit
submit -- Submit open files to the depot
p4 submit [-r -s -f option]
p4 submit [-r -s -f option] file
p4 submit [-r -f option] -d description
p4 submit [-r -f option] -d description file
p4 submit [-r -f option] -c changelist#
p4 submit -i [-r -s -f option]
'p4 submit' commits a pending changelist and its files to the depot.
By default, 'p4 submit' attempts to submit all files in the 'default'
changelist. Submit displays a dialog where you enter a description
of the change and, optionally, delete files from the list of files
to be checked in.
To add files to a changelist before submitting, use any of the
commands that open client workspace files: 'p4 add', 'p4 edit',
etc.
If the file parameter is specified, only files in the default
changelist that match the pattern are submitted.
Files in a stream path can be submitted only by client workspaces
dedicated to the stream. See 'p4 help client'.
Before committing a changelist, 'p4 submit' locks all the files being
submitted. If any file cannot be locked or submitted, the files are
left open in a numbered pending changelist. 'p4 opened' shows
unsubmitted files and their changelists.
Submit is atomic: if the operation succeeds, all files are updated
in the depot. If the submit fails, no depot files are updated.
The -c flag submits the specified pending changelist instead of the
default changelist. Additional changelists can be created manually,
using the 'p4 change' command, or automatically as the result of a
failed attempt to submit the default changelist.
The -d flag passes a description into the specified changelist rather
than displaying the changelist dialog for manual editing. This option
is useful for scripting, but does not allow you to add jobs or modify
the default changelist.
The -f flag enables you to override submit options that are configured
for the client that is submitting the changelist. This flag overrides
the -r (reopen)flag, if it is specified. See 'p4 help client' for
details about submit options.
The -i flag reads a changelist specification from the standard input.
The user's editor is not invoked.
The -r flag reopens submitted files in the default changelist after
submission.
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 details.
Flags for the resolved command.
No flags.
The -r flag reopens submitted files in the default changelist after
submission.
Options for Resolve command
Resolved command options.
p4 help resolved
resolved -- Show files that have been resolved but not submitted
p4 resolved [-o] [file ...]
'p4 resolved' lists file updates and integrations that have been
resolved but not yet submitted. To see unresolved integrations,
use 'p4 resolve -n'. To see already submitted integrations, use
'p4 integrated'.
If a depot file path is specified, the output lists resolves for
'theirs' files that match the specified path. If a client file
path is specified, the output lists resolves for 'yours' files
that match the specified path.
The -o flag reports the revision used as the base during the
resolve.
Flags for the revert command.
No flags.
The -a flag reverts only files that are open for edit or integrate
and are unchanged or missing. Files with pending integration records
are left open. The file arguments are optional when -a is specified.
The -n flag displays a preview of the operation.
The -k flag marks the file as reverted in server metadata without
altering files in the client workspace.
Revert command options.
p4 help revert
revert -- Discard changes from an opened file
p4 revert [-a -n -k -c changelist#] file ...
Revert an open file to the revision that was synced from the depot,
discarding any edits or integrations that have been made. You must
explicitly specify the files to be reverted. Files are removed from
the changelist in which they are open. Locked files are unlocked.
The -a flag reverts only files that are open for edit or integrate
and are unchanged or missing. Files with pending integration records
are left open. The file arguments are optional when -a is specified.
The -n flag displays a preview of the operation.
The -k flag marks the file as reverted in server metadata without
altering files in the client workspace.
The -c flag reverts files that are open in the specified changelist.
Flags for the shelve command.
No flags.
The -f (force) flag must be used with the -c or -i flag to overwrite
any existing shelved files in a pending changelist.
The -r flag (used with -c or -i) enables you to replace all shelved
files in that changelist with the files opened in your own workspace
at that changelist number. Only the user and client workspace of the
pending changelist can replace its shelved files.
The -d flag (used with -c) deletes the shelved files in the specified
changelist so that they can no longer be unshelved. By default, only
the user and client of the pending changelist can delete its shelved
files. A user with 'admin' access can delete shelved files by including
the -f flag to force the operation.
The -a flag enables you to handle unchanged files similarly to some
client submit options, namely 'submitunchanged' and 'leaveunchanged'.
The default behavior of shelving all files corresponds to the
'submitunchanged' option. The 'leaveunchanged' option only shelves
changed files, and then leaves the files opened in the pending
changelist on the client.
The -a flag enables you to handle unchanged files similarly to some
client submit options, namely 'submitunchanged' and 'leaveunchanged'.
The default behavior of shelving all files corresponds to the
'submitunchanged' option. The 'leaveunchanged' option only shelves
changed files, and then leaves the files opened in the pending
changelist on the client.
The -p flag promotes a shelved change from an edge server to a
commitserver where it can be accessed by other edge servers
participating in the distributed configuration. Once a shelved
change has been promoted, all subsequent local modifications to
the shelf are also pushed to the commit server and remain until
the shelf is deleted. Once a shelf has been created, the combination
of flags '-p -c' will promote the shelf without modification.
Shelve command options.
Shelve command options.
p4 help shelve
shelve -- Store files from a pending changelist into the depot
p4 shelve [files]
p4 shelve -i [-f | -r]
p4 shelve -r -c changelist#
p4 shelve -c changelist# [-f] [file ...]
p4 shelve -d -c changelist# [-f] [file ...]
'p4 shelve' creates, modifies or deletes shelved files in a pending
changelist. Shelved files remain in the depot until they are deleted
(using 'p4 shelve -d') or replaced by subsequent shelve commands.
After 'p4 shelve', the user can revert the files and restore them
later using 'p4 unshelve'. Other users can 'p4 unshelve' the stored
files into their own workspaces.
Files that have been shelved can be accessed by the 'p4 diff',
'p4 diff2', 'p4 files' and 'p4 print' commands using the revision
specification '@=change', where 'change' is the pending changelist
number.
By default, 'p4 shelve' creates a changelist, adds files from the
user's default changelist, then shelves those files in the depot.
The user is presented with a text changelist form displayed using
the editor configured using the $P4EDITOR environment variable.
If a file pattern is specified, 'p4 shelve' shelves the files that
match the pattern.
The -i flag reads the pending changelist specification with shelved
files from the standard input. The user's editor is not invoked.
To modify an existing changelist with shelved files, specify the
changelist number using the -c flag.
The -c flag specifies the pending changelist that contains shelved
files to be created, deleted, or modified. Only the user and client
of the pending changelist can add or modify its shelved files.
The -f (force) flag must be used with the -c or -i flag to overwrite
any existing shelved files in a pending changelist.
The -r flag (used with -c or -i) enables you to replace all shelved
files in that changelist with the files opened in your own workspace
at that changelist number. Only the user and client workspace of the
pending changelist can replace its shelved files.
The -d flag (used with -c) deletes the shelved files in the specified
changelist so that they can no longer be unshelved. By default, only
the user and client of the pending changelist can delete its shelved
files. A user with 'admin' access can delete shelved files by including
the -f flag to force the operation.
Flags for the sync command.
No flags.
The -f flag forces resynchronization even if the client already
has the file, and overwriting any writable files. This flag doesn't
affect open files.
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
The -n flag previews the operation without updating the workspace.
The -k flag updates server metadata without syncing files. It is
intended to enable you to ensure that the server correctly reflects
the state of files in the workspace while avoiding a large data
transfer. Caution: an erroneous update can cause the server to
incorrectly reflect the state of the workspace.
The -p flag populates the client workspace, but does not update the
server to reflect those updates. Any file that is already synced or
opened will be bypassed with a warning message. This option is very
useful for build clients or when publishing content without the
need to track the state of the client workspace.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are not suppressed.
The -s flag adds a safety check before sending content to the client
workspace. This check uses MD5 digests to compare the content on the
clients workspace against content that was last synced. If the file
has been modified outside of Perforce's control then an error message
is displayed and the file is not overwritten. This check adds some
extra processing which will affect the performance of the operation.
Sync command options.
Sync command options.
p4 help sync
sync -- Synchronize the client with its view of the depot
flush -- synonym for 'sync -k'
update -- synonym for 'sync -s'
p4 sync [-f -L -n -k -q] [-m max] [file[revRange] ...]
p4 sync [-L -n -q -s] [-m max] [file[revRange] ...]
p4 sync [-L -n -p -q] [-m max] [file[revRange] ...]
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 maps client and depot file names and
locations.
Sync adds files that are in the client view and have not been
retrieved before. Sync deletes previously retrieved files that
are no longer in the client view or have been deleted from the
depot. Sync updates files that are still in the client view and
have been updated in the depot.
By default, sync affects all files in the client workspace. If file
arguments are given, sync limits its operation to those files.
The file arguments can contain wildcards.
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.
If the file argument includes a revision range specification,
only files selected by the revision range are updated, and the
highest revision in the range is used.
Normally, sync does not overwrite workspace files that the user has
manually made writable. Setting the 'clobber' option in the
client specification disables this safety check.
The -f flag forces resynchronization even if the client already
has the file, and overwriting any writable files. This flag doesn't
affect open files.
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
The -n flag previews the operation without updating the workspace.
The -k flag updates server metadata without syncing files. It is
intended to enable you to ensure that the server correctly reflects
the state of files in the workspace while avoiding a large data
transfer. Caution: an erroneous update can cause the server to
incorrectly reflect the state of the workspace.
The -p flag populates the client workspace, but does not update the
server to reflect those updates. Any file that is already synced or
opened will be bypassed with a warning message. This option is very
useful for build clients or when publishing content without the
need to track the state of the client workspace.
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are not suppressed.
The -s flag adds a safety check before sending content to the client
workspace. This check uses MD5 digests to compare the content on the
clients workspace against content that was last synced. If the file
has been modified outside of Perforce's control then an error message
is displayed and the file is not overwritten. This check adds some
extra processing which will affect the performance of the operation.
The -m flag limits sync to the first 'max' number of files. This
option is useful in conjunction with tagged output and the '-n'
flag, to preview how many files will be synced without transferring
all the file data.
Flags for the unlock command.
No flags.
By default, files can be unlocked only by the changelist owner. The
-f flag enables you to unlock files in changelists owned by other
users. The -f flag requires 'admin' access, which is granted by 'p4
protect'.
Unlock command options.
Unlock command options.
p4 help unlock
unlock -- Release a locked file, leaving it open
p4 unlock [-c changelist#] [-f] [file ...]
'p4 unlock' releases locks on the specified files, which must be
open in the specified pending changelist. If you omit the changelist
number, the default changelist is assumed. If you omit the file name,
all locked files are unlocked.
By default, files can be unlocked only by the changelist owner. The
-f flag enables you to unlock files in changelists owned by other
users. The -f flag requires 'admin' access, which is granted by 'p4
protect'.
Flags for the unshelve command.
No flags.
The -f flag forces the clobbering of any writeable but unopened files
that are being unshelved.
The -n flag previews the operation without changing any files or
metadata.
Unshelve command options.
Unshelve command options.
p4 help unshelve
unshelve -- Restore shelved files from a pending change into a workspace
p4 unshelve -s changelist# [-f -n] [-c changelist#] [file ...]
'p4 unshelve' retrieves shelved files from the specified pending
changelist, opens them in a pending changelist and copies them
to the invoking user's workspace. Unshelving files from a pending
changelist is restricted by the user's permissions on the files.
A successful unshelve operation places the shelved files on the
user's workspace with the same open action and pending integration
history as if it had originated from that user and client.
Unshelving a file over an already opened file is only permitted
if both shelved file and opened file are opened for 'edit'. After
unshelving, the workspace file is flagged as unresolved, and
'p4 resolve' must be run to resolve the differences between the
shelved file and the workspace file.
The -s flag specifies the number of the pending changelist that
contains the shelved files.
If a file pattern is specified, 'p4 unshelve' unshelves files that
match the pattern.
The -c flag specifies the changelist to which files are unshelved.
By default, 'p4 unshelve' opens shelved files in the default
changelist.
The -f flag forces the clobbering of any writeable but unopened files
that are being unshelved.
The -n flag previews the operation without changing any files or
metadata.
Flags for the copy command.
No flags.
The -n flag displays a preview of the copy, without actually doing
anything.
The -v flag causes a 'virtual' copy that does not modify client
workspace files. After submitting a virtual integration, 'p4 sync'
can be used to update the workspace.
The -r flag causes the direction of the copy to be reversed when
used with a branch (-b) or stream (-S) copy.
The -F flag can be used with -S to force copying even though the
stream does not expect a copy to occur in the direction indicated.
Normally 'p4 copy' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the user-defined branch view to be
treated as the target, per the branch view mapping. Optional toFile
arguments may be given to further restrict the scope of the target
file set. -r is ignored when -s is used.
Copy command options.
Copy command options.
p4 help copy
copy -- Copy one set of files to another
p4 copy [options] fromFile[rev] toFile
p4 copy [options] -b branch [-r] [toFile[rev] ...]
p4 copy [options] -b branch -s fromFile[rev] [toFile ...]
p4 copy [options] -S stream [-P parent] [-F] [-r] [toFile[rev] ...]
options: -c changelist# -n -v -m max
'p4 copy' copies one set of files (the 'source') into another (the
'target').
Using the client workspace as a staging area, 'p4 copy' makes the
target identical to the source by branching, replacing, or deleting
files. 'p4 submit' submits copied files to the depot. 'p4 revert'
can be used to revert copied files instead of submitting them. The
history of copied files can be shown with 'p4 filelog' or 'p4
integrated'.
Target files that are already identical to the source, or that are
outside of the client view, are not affected by 'p4 copy'. Opened,
non-identical target files cause 'p4 copy' to exit with a warning.
When 'p4 copy' creates or modifies files in the workspace, it leaves
them read-only; 'p4 edit' can make them writable. Files opened by
'p4 copy' do not need to be resolved.
Source and target files (fromFile and toFile) can be specified on
the 'p4 copy' command line or through a branch view. On the command
line, fromFile is the source file set and toFile is the target file
set. With a branch view, one or more toFile arguments can be given
to limit the scope of the target file set.
A revision specifier can be used to select the revision to copy; by
default, the head revision is copied. The revision specifier can be
used on fromFile, or on toFile, but not on both. When used on toFile,
it refers to source revisions, not to target revisions. A range may
not be used as a revision specifier. For revision syntax, see 'p4
help revisions'.
The -S flag makes 'p4 copy' use a stream's branch view. (See 'p4 help
stream'.) The source is the stream itself, and the target is the
stream's parent. With -r, the direction is reversed. -P can be used
to specify a parent stream other than the stream's actual parent.
Note that to submit copied stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -F flag can be used with -S to force copying even though the
stream does not expect a copy to occur in the direction indicated.
Normally 'p4 copy' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -b flag makes 'p4 copy' use a user-defined branch view. (See
'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the user-defined branch view to be
treated as the target, per the branch view mapping. Optional toFile
arguments may be given to further restrict the scope of the target
file set. -r is ignored when -s is used.
The -c changelist# flag opens files in the designated (numbered)
pending changelist instead of the default changelist.
The -n flag displays a preview of the copy, without actually doing
anything.
The -m flag limits the actions to the first 'max' number of files.
The -v flag causes a 'virtual' copy that does not modify client
workspace files. After submitting a virtual integration, 'p4 sync'
can be used to update the workspace.
Flags for the merge command.
No flags.
The -n flag displays a preview of the copy, without actually doing
anything.
The -r flag causes the direction of the copy to be reversed when
used with a branch (-b) or stream (-S) copy.
The -F flag can be used with -S to force copying even though the
stream does not expect a copy to occur in the direction indicated.
Normally 'p4 copy' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the user-defined branch view to be
treated as the target, per the branch view mapping. Optional toFile
arguments may be given to further restrict the scope of the target
file set. -r is ignored when -s is used.
Merge command options.
p4 help merge
merge -- Merge one set of files into another
p4 merge [options] fromFile[revRange] toFile
p4 merge [options] -b branch [-r] [toFile[revRange] ...]
p4 merge [options] -b branch -s fromFile[revRange] [toFile ...]
p4 merge [options] -S stream [-P parent] [-F] [-r] [toFile[revRange] ...]
options: -c changelist# -n -m max
'p4 merge' merges changes from one set of files (the 'source') into
another (the 'target'). It is a simplified form of the 'p4 integrate'
command.
Using the client workspace as a staging area, 'p4 merge' branches and
deletes target files per changes in the source, and schedules all
other affected target files to be resolved. Target files outside of
the current client view are not affected. Source files need not be
within the client view.
'p4 resolve' must be used to merge file content, and to resolve
filename and filetype changes. 'p4 submit' commits merged files to
the depot. Unresolved files may not be submitted. Merged files can
be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
commands 'p4 integrated' and 'p4 filelog' display merge history.
When 'p4 merge' schedules a workspace file to be resolved, it leaves
it read-only. 'p4 resolve' can operate on a read-only file; for
other pre-submit changes, 'p4 edit' must be used to make the file
writable.
Source and target files can be specified either on the 'p4 merge'
command line or through a branch view. On the command line, fromFile
is the source file set and toFile is the target file set. With a
branch view, one or more toFile arguments can be given to limit the
scope of the target file set.
Each file in the target is mapped to a file in the source. Mapping
adjusts automatically for files that have been moved or renamed, as
long as 'p4 move' was used to move/rename files. The scope of source
and target file sets must include both old-named and new-named files
for mappings to be adjusted. Moved source files may schedule moves
to be resolved in target files.
revRange is a revision or a revision range that limits the span of
source history to be probed for unintegrated revisions. revRange
can be used on fromFile, or on toFile, but not on both. When used
on toFile, it refers to source revisions, not to target revisions.
For details about revision specifiers, see 'p4 help revisions'.
The -S flag makes 'p4 merge' use a stream's branch view. (See 'p4
help stream'.) The source is the stream itself, and the target is
the stream's parent. With -r, the direction is reversed. -P can be
used to specify a parent stream other than the stream's actual parent.
Note that to submit merged stream files, the current client must
be dedicated to the target stream. (See 'p4 help client'.)
The -F flag can be used with -S to force merging even though the
stream does not expect a merge to occur in the direction indicated.
Normally 'p4 merge' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
The -b flag makes 'p4 merge' use a user-defined branch view. (See
'p4 help branch'.) The source is the left side of the branch view
and the target is the right side. With -r, the direction is reversed.
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the branch view to be treated as the
target, per the branch view mapping. Optional toFile arguments may
be given to further restrict the scope of the target file set. The
-r flag is ignored when -s is used.
Flags for the fix command.
No flags.
The -d flag deletes the specified fixes. This operation does not
otherwise affect the specified changelist or jobs.
Fix command options.
Fix command options.
p4 help fix
fix -- Mark jobs as being fixed by the specified changelist
p4 fix [-d] [-s status] -c changelist# jobName ...
'p4 fix' marks each named job as being fixed by the changelist
number specified with -c. The changelist can be pending or
submitted and the jobs can open or closed (fixed by another
changelist).
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 is closed when the
changelist is submitted. If the job is already closed, it remains
closed.
The -d flag deletes the specified fixes. This operation does not
otherwise affect the specified changelist or jobs.
The -s flag uses the specified status instead of the default defined
in the job specification. This status is reported by 'p4 fixes'.
The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit'
(of a pending changelist) commands set the job's status to the fix's
status for each job associated with the change. If the fix's status
is 'same', the job's status is left unchanged.
Flags for the user command.
No flags.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
User command options.
User command options.
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
Flags for the users command.
No flags.
The -a flag includes service and operator users in the output.
The -l flag includes additional information in the output. The -l
flag requires 'super' access, which is granted by 'p4 protect'.
Users command options
Users command options.
p4 help users
users -- List Perforce users
p4 users [-l -a -r -c] [-m max] [user ...]
Lists all Perforce users or users that match the 'user' argument.
The report includes the last time that each user accessed the system.
The -m max flag limits output to the first 'max' number of users.
The -a flag includes service and operator users in the output.
The -l flag includes additional information in the output. The -l
flag requires 'super' access, which is granted by 'p4 protect'.
The -r and -c flags are only allowed on replica servers. When
-r is given only users who have used a replica are reported and
when -c is given only the user information from the central server
is reported. Otherwise on a replica server, the user list will
be slightly different from the master server as the user access times
will reflect replica usage or master usage whichever is newer.
Flags for the client command.
No flags.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Client command options
Client command options.
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [-f] name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
Client command options.
p4 help client
client -- Create or edit a client workspace specification and its view
workspace -- Synonym for 'client'
p4 client [-f -t template] [name]
p4 client -d [-f] name
p4 client -o [-t template] [name]
p4 client -S stream [[-c change] -o] [name]
p4 client -s [-f] -S stream [name]
p4 client -s [-f] -t template [name]
p4 client -i [-f]
Creates a new client specification ('spec') or edits an existing
spec. A client spec is a named mapping of depot files to workspace
files.
The 'p4 client' command puts the client spec into a temporary file
and invokes the editor configured by the environment variable
$P4EDITOR. For new workspaces, the client name defaults to the
$P4CLIENT environment variable, if set, or to the current host name.
Saving the file creates or modifies the client spec.
The client spec contains the following fields:
Client: The client name.
Host: If set, restricts access to the named host.
If unset, access is allowed from any host.
Owner: The user who created this client.
Update: The date that this spec was last modified.
Access: The date that this client was last used in any way.
Description: A short description of the workspace.
Root: The root directory of the workspace (specified in local
file system syntax), under which all versioned files
will be placed. If you change this setting, you must
physically relocate any files that currently reside
there. On Windows client machines, you can specify the
root as "null" to enable you to map files to multiple
drives.
AltRoots: Up to two optional alternate client workspace roots.
The first of the main and alternate roots to match the
client program's current working directory is used. If
none match, the main root is used. 'p4 info' displays
the root that is being used.
Options: Flags to configure the client behavior. Defaults
are marked with *.
allwrite Leaves all files writable on the client;
noallwrite * by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option
(see below).
clobber Permits 'p4 sync' to overwrite writable
noclobber * files on the client. noclobber is ignored if
allwrite is set.
compress Compresses data sent between the client
nocompress * and server to speed up slow connections.
locked Allows only the client owner to use or change
unlocked * the client spec. Prevents the client spec from
being deleted.
modtime Causes 'p4 sync' and 'p4 submit' to preserve
nomodtime * file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
rmdir Makes 'p4 sync' attempt to delete a workspace
normdir * directory when all files in it are removed.
SubmitOptions: Flags to change submit behaviour.
submitunchanged All open files are submitted (default).
revertunchanged Files that have content or type changes
are submitted. Unchanged files are
reverted.
leaveunchanged Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
+reopen Can be appended to the submit option flag
to cause submitted files to be reopened in
the default changelist.
Example: submitunchanged+reopen
LineEnd: Set line-ending character(s) for client text files.
local mode that is native to the client (default).
unix linefeed: UNIX style.
mac carriage return: Macintosh style.
win carriage return-linefeed: Windows style.
share hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
View: Maps files in the depot to files in your client
workspace. Defines the files that you want in your
client workspace and specifies where you want them
to reside. 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'.
Stream: The stream to which this client's view will be dedicated.
(Files in stream paths can be submitted only by dedicated
stream clients.) When this optional field is set, the
View field will be automatically replaced by a stream
view as the client spec is saved.
Note: changing the client root does not actually move the client
files; you must relocate them manually. Similarly, changing
the 'LineEnd' option does not actually update the client files;
you can refresh them with 'p4 sync -f'.
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete.
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
The -t template flag, where 'template' is the name of another client
spec, causes the View and Options fields to be replaced by those of
the template.
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
Without -s, the '-S stream' flag can be used to create a new client
spec dedicated to a stream. If the client spec already exists, and
-S is used without -s, it is ignored.
The '-S stream' flag can be used with '-o -c change' to inspect an
old stream client view. It yields the client spec that would have
been created for the stream at the moment the change was recorded.
Flags for the clients command.
No flags.
The -t flag displays the time as well as the date.
The -e nameFilter flag lists workspaces with a name that matches
the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes
the matching case-insensitive.
Clients command options
Clients command options.
p4 help clients
clients -- Display list of clients
workspaces -- synonym for 'clients'
p4 clients [-t] [-u user] [[-e|-E] nameFilter -m max] [-S stream]
Lists all client workspaces currently defined in the server.
The -t flag displays the time as well as the date.
The -u user flag lists client workspaces that are owned by the
specified user.
The -e nameFilter flag lists workspaces with a name that matches
the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes
the matching case-insensitive.
The -m max flag limits output to the specified number of workspaces.
The -S stream flag limits output to the client workspaces dedicated
to the stream.
Flags for the change command.
No flags.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. The -f flag requires 'admin' access granted by 'p4
protect'. The -f and -u flags are mutually exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
Change command options.
Change command options.
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [changelist#]
p4 change -d [-f -s] changelist#
p4 change -o [-s] [-f] [changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-f | -u] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. The -f flag requires 'admin' access granted by 'p4
protect'. The -f and -u flags are mutually exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
Change command options.
p4 help change
change -- Create or edit a changelist description
changelist -- synonym for 'change'
p4 change [-s] [-f | -u] [changelist#]
p4 change -d [-f -s] changelist#
p4 change -o [-s] [-f] [changelist#]
p4 change -i [-s] [-f | -u]
p4 change -t restricted | public [-f | -u] changelist#
'p4 change' creates and edits changelists and their descriptions.
With no argument, 'p4 change' creates a new changelist. If a
changelist number is specified, '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.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -f flag forces the update or deletion of other users' pending
changelists. -f can also force the deletion of submitted changelists
after they have been emptied of files using 'p4 obliterate'. By
default, submitted changelists cannot be changed. The -f flag can
also force display of the 'Description' field in a restricted
changelist. The -f flag requires 'admin' access granted by 'p4
protect'. The -f and -u flags are mutually exclusive.
The -u flag can force the update of a submitted change by the owner
of the change. Only the Jobs, Type, and Description fields can be
changed using the -u flag. The -f and -u flags cannot be used in
the same change command.
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 exists
to support integration with external defect trackers.
The -t flag changes the 'Type' of the change to 'restricted'
or 'public' without displaying the change form. This option is
useful for running in a trigger or script.
The 'Type' field can be used to hide the change or its description
from users. Valid values for this field are 'public' (default), and
'restricted'. A shelved or committed change that is 'restricted' is
accessible only to users who own the change or have 'list' permission
to at least one file in the change. A pending (not shelved) change
is accessible to its owner. Public changes are accessible to all
users. This setting affects the output of the 'p4 change',
'p4 changes', and 'p4 describe' commands.
If a user is not permitted to have access to a restricted change,
The 'Description' text is replaced with a 'no permission' message
(see 'Type' field). Users with admin permission can override the
restriction using the -f flag.
Flags for the changes command.
No flags.
The -i flag also includes any changelists integrated into the
specified files.
The -t flag displays the time as well as the date.
The -l flag displays the full text of the changelist
descriptions.
The -L flag displays the changelist descriptions, truncated to 250
characters if longer.
The -f flag enables admin users to view restricted changes.
Flags for the status of a changelist.
No status specified.
Pending changelist.
Shelved changelist.
Submitted changelist.
Changes command options.
Changes command options.
p4 help changes
changes -- Display list of pending and submitted changelists
changelists -- synonym for 'changes'
p4 changes [options] [file[revRange] ...]
options: -i -t -l -L -f -c client -m max -s status -u user
Returns a list of all pending and submitted changelists currently
stored in the server.
If files are specified, 'p4 changes' lists only changelists that
affect those files. If the file specification includes a revision
range, 'p4 changes' lists only submitted changelists that affect
the specified revisions. See 'p4 help revisions' for details.
If files are not specified, 'p4 changes' limits its report
according to each change's type ('public' or 'restricted').
If a submitted or shelved change is restricted, the change is
not reported unless the user owns the change or has list
permission for at least one file in the change. Only the owner
of a restricted and pending (not shelved) change is permitted
to see it.
The -i flag also includes any changelists integrated into the
specified files.
The -t flag displays the time as well as the date.
The -l flag displays the full text of the changelist
descriptions.
The -L flag displays the changelist descriptions, truncated to 250
characters if longer.
The -f flag enables admin users to view restricted changes.
The -c client flag displays only submitted by the specified client.
The -m max flag limits changes to the 'max' most recent.
The -s status flag limits the output to pending, shelved or
submitted changelists.
The -u user flag displays only changes owned by the specified user.
Flags for the group command.
No flags.
The -d flag deletes a pending changelist, 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 be deleted only by the user and client
who created it, or by a user with 'admin' privilege using the -f
flag.
The -o flag writes the changelist specification to the standard
output. The user's editor is not invoked.
The -i flag reads a changelist specification from the standard
input. The user's editor is not invoked.
The -a flag enables a user without 'super' access to modify the group
if that user is an 'owner' of that group. Group owners are specified
in the 'Owners' field of the group spec.
The -A flag enables a user with 'admin' access to add a new group.
Existing groups may not be modified when this flag is used.
Group command options.
Group command options.
p4 help group
group -- Change members of user group
p4 group [-a] name
p4 group -d [-a] name
p4 group -o name
p4 group -i [-a]
Create a group or modify the membership of an existing group.
A group can contain users and other groups. The group specification
is put into a temporary file and the editor (configured by the
environment variable $P4EDITOR) is invoked.
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.
Each group has MaxResults, MaxScanRows, and MaxLockTime fields,
which limit the resources committed to operations performed by
members of the group. For these fields, 'unlimited' or 'unset'
means no limit for that group. An individual user's limit is the
highest of any group with a limit to which he belongs, unlimited if
any of his groups has 'unlimited' for that field, or unlimited
if he belongs to no group with a limit. See 'p4 help maxresults'
for more information on MaxResults, MaxScanRows and MaxLockTime.
Each group also has a Timeout field, which specifies how long (in
seconds) a 'p4 login' ticket remains valid. A value of 'unset' or
'unlimited' is equivalent to no timeout. An individual's timeout is
the highest of any group with a limit to which he belongs, unlimited
if any of his groups has 'unlimited' for the timeout value, or
unlimited if he belongs to no group with a limit. See 'p4 help login'
for more information.
Each group has a PasswordTimeout field, which determines how long a
password remains valid for members of the group.
The -d flag deletes a group.
The -o flag writes the group specification to standard output. The
user's editor is not invoked.
The -i flag reads a group specification from standard input. The
user's editor is not invoked. The new group specification replaces
the previous one.
The -a flag enables a user without 'super' access to modify the group
if that user is an 'owner' of that group. Group owners are specified
in the 'Owners' field of the group spec.
All commands that require access granted by 'p4 protect' consider a
user's groups when calculating access levels.
'p4 group' requires 'super' access granted by 'p4 protect' unless
invoked with the '-a' flag by a qualified user.
Flags for the groups command.
No flags.
The -i flag also displays groups that the user or group belongs to
indirectly by means of membership in subgroups.
(The group parameter for the command can be a user or group name)
The -v flag displays the MaxResults, MaxScanRows, MaxLockTime, and
Timeout values for the specified group.
Groups command options.
Flags for the job command.
No flags.
The -d flag deletes the specified job. You cannot delete a job if
it has pending or submitted fixes associated with it.
The -o flag writes the job specification to the standard output.
The user's editor is not invoked.
The -i flag reads a job specification from the standard input. The
user's editor is not invoked.
The -f flag enables you set fields that are read-only by default.
The -f flag requires 'admin' access, which is granted using the
'p4 protect' command.
Job command options
Options for job command.
p4 help job
job -- Create or edit a job (defect) specification
p4 job [-f] [jobName]
p4 job -d jobName
p4 job -o [jobName]
p4 job -i [-f]
The 'p4 job' command 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 associates changelists with jobs.
With no arguments, 'p4 job' creates an empty job specification
and invokes the user's editor. When the specification is saved,
a job name of the form jobNNNNNN is assigned. If the jobName
parameter is specified on the command line, the job is created or
opened for editing.
As jobs are entered or updated, all fields are indexed for searching
Text fields are broken into individual alphanumeric words (punctuation
and whitespace are ignored) and each word is case-folded and entered
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.
The fields that compose a job are defined by the 'p4 jobspec' command.
Perforce provides a default job specification that you can edit.
The -d flag deletes the specified job. You cannot delete a job if
it has pending or submitted fixes associated with it.
The -o flag writes the job specification to the standard output.
The user's editor is not invoked.
The -i flag reads a job specification from the standard input. The
user's editor is not invoked.
The -f flag enables you set fields that are read-only by default.
The -f flag requires 'admin' access, which is granted using the
'p4 protect' command.
Flags for the jobs command.
No flags.
The -i flag includes any fixes made by changelists integrated into
the specified files.
The -l flag produces long output with the full text of the job
descriptions.
The -r flag sorts the jobs in reverse order (by job name).
The -R flag rebuilds the jobs table and reindexes each job, which
is necessary after upgrading to 98.2. 'p4 jobs -R' requires that
that the user be an operator or have 'super' access granted by
'p4 protect'.
Jobs command options
Jobs command options.
p4 help jobs
jobs -- Display list of jobs
p4 jobs [-e jobview -i -l -m max -r] [file[revRange] ...]
p4 jobs -R
Lists jobs in the server. If a file specification is included, fixes
for submitted changelists affecting the specified files are listed.
The file specification can include wildcards and a revision range.
See 'p4 help revisions' for details about specifying revisions.
The -e flag lists jobs matching the expression specified in the
jobview parameter. For a description of jobview syntax, see 'p4 help
jobview'.
The -i flag includes any fixes made by changelists integrated into
the specified files.
The -l flag produces long output with the full text of the job
descriptions.
The -m max flag limits the output to the first 'max' jobs, ordered
by their job name.
The -r flag sorts the jobs in reverse order (by job name).
The -R flag rebuilds the jobs table and reindexes each job, which
is necessary after upgrading to 98.2. 'p4 jobs -R' requires that
that the user be an operator or have 'super' access granted by
'p4 protect'.
Flags for the files command.
No flags.
The -a flag displays all revisions within the specific range, rather
than just the highest revision in the range.
The -A flag displays files in archive depots.
Files command options
Options for the files command.
p4 help Files
Flags for the filelog command.
No flags.
The -i flag, includes inherited file history. If a file was created by
branching (using 'p4 integrate'), filelog lists the revisions of the
file's ancestors up to the branch points that led to the specified
revision. File history inherited by renaming (using 'p4 move') is
always displayed regardless of whether -i is specified.
The -h flag, displays file content history instead of file name
history. The list includes revisions of other files that were
branched or copied (using 'p4 integrate' and 'p4 resolve -at') to
the specified revision. Revisions that were replaced by copying
or branching are omitted, even if they are part of the history of
the specified revision.
The -t flag, displays the time as well as the date.
The -l flag lists the full text of the changelist descriptions.
The -L flag lists the full text of the changelist descriptions,
truncated to 250 characters if longer.
The -s flag displays a shortened form of filelog that omits
non-contributory integrations.
Options for the filelog command.
Options for the filelog command.
Flags for the login command.
No flags.
The -a flag causes the server to issue a ticket that is valid on all
host machines.
The -p flag displays the ticket, but does not store it on the client
machine.
The -s flag displays the status of the current ticket (if there is
one).
Options for the login command.
Options for the login command.
Flags for the logout command.
No flags.
The -a flag causes the server to issue a ticket that is valid on all
host machines.
Options for the logout command.
Options for the logout command.
Flags for the tag command.
No flags.
The -d deletes the association between the specified files and the
label, regardless of revision.
The -n flag previews the results of the operation.
Tag command options
Options for the tag command.
Flags for the stream command.
No flags.
The -d flag deletes the specified stream (unless the stream is
referenced by child streams or stream clients).
The -o flag writes the stream specification to the standard output.
The user's editor is not invoked.
The -v may be used with -o to expose the automatically generated
client view for this stream.
The -i flag reads a stream specification from the standard input.
The user's editor is not invoked.
The -f flag allows a user other than the owner to modify or delete
a locked stream. It requires 'admin' access granted by 'p4 protect'.
Stream command options
Stream command options
Flags for the streams command.
No flags.
Streams command options
Streams command options
Flags for the istat command.
No flags.
The -r flag shows the status of integration to the stream from its
parent. By default, status of integration in the other direction is
shown, from the stream to its parent.
The -a flag shows status of integration in both directions.
The -c flag forces 'p4 istat' to assume the cache is stale; it
causes a search for pending integrations. Use of this flag can
impact server performance.
The -s flag shows cached state without refreshing stale data.
GetStreamMetaData command options
Stream command options
Flags for the depot command.
No flags.
The -d flag deletes the specified depot. If any files reside in
the depot, they must be removed with 'p4 obliterate' before
deleting the depot.
The -o flag writes the depot specification to the standard output.
The user's editor is not invoked.
The -i flag reads a depot specification from the standard input.
The user's editor is not invoked.
depot command options
Options for the depot command
Flags for the branch command.
No flags.
The -d flag deletes the named branch spec.
The -o flag writes the branch spec to standard output.
The user's editor is not invoked.
The -i flag reads a branch specification from the standard input.
The user's editor is not invoked.
The -f flag enables a user with 'admin' privilege to delete the
spec or set the 'last modified' date. By default, specs can be
deleted only by their owner.
Branch command options
Branch command options
Flags for the branches command.
No flags.
The -t flag displays the time as well as the date.
The -e nameFilter flag lists branchspecs with a name that matches
the nameFilter pattern, for example: -e 'branchspec*'. -E makes
the matching case-insensitive.
Branches command options
Branches command options
Flags for the label command.
No flags.
The -d flag deletes the named label spec.
The -o flag writes the label spec to standard output.
The user's editor is not invoked.
The -i flag reads a label specification from the standard input.
The user's editor is not invoked.
The -f flag forces the deletion of a label. By default, locked
labels can only be deleted by their owner. The -f flag also
permits the Last Modified date to be set. The -f flag requires
'admin' access, which is granted by 'p4 protect'.
The -g flag should be used on an Edge Server to update a global
label. Without -g, the label definition is visible only to users
of this Edge Server. Configuring rpl.labels.global=1 reverses this
default and causes this flag to have the opposite meaning.
Label command options
Label command options
Flags for the labels command.
No flags.
The -t flag displays the time as well as the date.
The -e nameFilter flag lists labels with a name that matches
the nameFilter pattern, for example: -e 'label*'. -E makes
the matching case-insensitive.
The -U flag lists unloaded labels (see 'p4 help unload').
The -a flag specifies that all labels should be displayed,
not just those that are bound to this server.
Labels command options
Labels command options
Labels command options
Flags for the diff2 command.
No flags.
-dn RCS output
-dc[n] context
-ds summary
-du[n] unified
-db ignore whitespace changes
-dw ignore whitespace
-dl ignore line endings
The -Od flag limits output to files that differ.
The -q omits files that have identical content and types and
suppresses the actual diff for all files.
The -t flag forces 'p4 diff2' to diff binary files.
The -u flag uses the GNU diff -u format and displays only files
that differ. The file names and dates are in Perforce syntax, but
but the output can be used by the patch program.
Diff2 command options
Diff2 command options
Flags for the opened command.
No flags.
The -a flag lists opened files in all clients. By default,
only files opened by the current client are listed.
The -s option produces 'short' and optimized output when used
with the -a (all clients) option. For large repositories '-a'
can take a long time when compared to '-as'.
The -x option lists files that are opened 'exclusive'. This
option only applies to a distributed installation where global
tracking of these file types is necessary across servers. The
-x option implies the -a option.
GetOpenedFiles options
Options for GetOpenedFiles
p4 help opened
opened -- List open files and display file status
p4 opened [-a -c changelist# -C client -u user -m max -s] [file ...]
p4 opened [-a -x -m max ] [file ...]
Lists files currently opened in pending changelists, or, for
specified files, show whether they are currently opened or locked.
If the file specification is omitted, all files open in the current
client workspace are listed.
Files in shelved changelists are not displayed by this command. To
display shelved changelists, see 'p4 changes -s shelved'; to display
the files in those shelved changelists, see 'p4 describe -s -S'.
The -a flag lists opened files in all clients. By default, only
files opened by the current client are listed.
The -c changelist# flag lists files opened in the specified
changelist#.
The -C client flag lists files open in the specified client workspace.
The -u user flag lists files opened by the specified user.
The -m max flag limits output to the first 'max' number of files.
The -s option produces 'short' and optimized output when used with
the -a (all clients) option. For large repositories '-a' can take
a long time when compared to '-as'.
The -x option lists files that are opened 'exclusive'. This option
only applies to a distributed installation where global tracking of
these file types is necessary across servers. The -x option implies
the -a option.
Flags for the fstat command.
No flags.
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
The -r flag sorts the output in reverse order.
-Oa output attributes set by 'p4 attribute'.
-Od output the digest of the attribute.
-Oe output attribute values encoded as hex
-Of output all revisions for the given files (this
option suppresses other* and resolve* fields)
-Ol output a fileSize and digest field for each revision
(this may be expensive to compute)
-Op output the local file path in both Perforce syntax
(//client/) as 'clientFile' and host form as 'path'
-Os exclude client-related data from output
-Rc limit output to files mapped in the client view
-Rh limit output to files synced to the client workspace
-Rn limit output to files opened not at the head revision
-Ro limit output to files opened
-Rr limit output to files opened that have been resolved
-Rs limit output to files shelved (requires -e)
-Ru limit output to files opened that need resolving
-St sort by filetype
-Sd sort by date
-Sr sort by head revision
-Sh sort by have revision
-Ss sort by filesize
-U displays information about unload files in
the unload depot (see 'p4 help unload').
GetFileMetaData options (uses the fstat command)
Flags for the files command.
No flags.
The -a flag displays all revisions within the specific range,
rather than just the highest revision in the range.
The -A flag displays files in archive depots.
The -e flag displays files with an action of anything other
than deleted, purged or archived. Typically this revision
is always available to sync or integrate from.
The -U option displays files in the unload depot (see 'p4
help unload' for more information about the unload depot).
Options for the files command
p4 help files
files -- List files in the depot
p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
p4 files -U unloadfile ...
List details about specified files: depot file name, revision,
file, type, change action and changelist number of the current
head revision. If client syntax is used to specify the file
argument, the client view mapping is used to determine the
corresponding depot files.
By default, the head revision is listed. If the file argument
specifies a revision, then all files at that revision are listed.
If the file argument specifies a revision range, the highest revision
in the range is used for each file. For details about specifying
revisions, see 'p4 help revisions'.
The -a flag displays all revisions within the specific range, rather
than just the highest revision in the range.
The -A flag displays files in archive depots.
The -e flag displays files with an action of anything other than
deleted, purged or archived. Typically this revision is always
available to sync or integrate from.
The -m flag limits files to the first 'max' number of files.
The -U option displays files in the unload depot (see 'p4 help unload'
for more information about the unload depot).
Flags for the dirs command.
No flags.
The -C flag lists only directories that fall within the
current client view.
The -D flag includes directories containing only deleted
files.
The -H flag lists directories containing files synced to
the current client workspace.
dirs command options
Flags for the print command.
No flags.
The -a flag prints all revisions within the specified range, rather
than just the highest revision in the range.
The -q flag suppresses the initial line that displays the file name
and revision.
Print command options
Command options for GetFileContentsCmd()
p4 help print
print -- Write a depot file to standard output
p4 print [-a -o localFile -q] file[revRange] ...
Retrieve the contents of a depot file to the client's standard output.
The file is not synced. If file is specified using client syntax,
Perforce uses the client view to determine the corresponding depot
file.
By default, the head revision is printed. If the file argument
includes a revision, the specified revision is 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 printed. For details about revision specifiers, see 'p4
help revisions'.
The -a flag prints all revisions within the specified range, rather
than just the highest revision in the range.
The -o localFile flag redirects the output to the specified file on
the client filesystem.
The -q flag suppresses the initial line that displays the file name
and revision.
Flags for the filelog command.
No flags.
The -i flag includes inherited file history. If a file was created by
branching (using 'p4 integrate'), filelog lists the revisions of the
file's ancestors up to the branch points that led to the specified
revision. File history inherited by renaming (using 'p4 move') is
always displayed regardless of whether -i is specified.
The -h flag displays file content history instead of file name
history. The list includes revisions of other files that were
branched or copied (using 'p4 integrate' and 'p4 resolve -at') to
the specified revision. Revisions that were replaced by copying
or branching are omitted, even if they are part of the history of
the specified revision.
The -t flag displays the time as well as the date.
The -l flag lists the full text of the changelist descriptions.
The -L flag lists the full text of the changelist descriptions,
truncated to 250 characters if longer.
The -s flag displays a shortened form of filelog that omits
non-contributory integrations.
Filelog command options
Filelog command options
Flags for the annotate command.
No flags.
The -a flag includes both deleted files and lines no longer
present at the head revision. In the latter case, both the
starting and ending revision for each line is displayed.
The -c flag directs the annotate command to output changelist
numbers rather than revision numbers for each line.
-db Ignore Whitespace Changes
-dw Ingore whitespace altogether.
-dl Ignore Line Endings
The -i flag follows branches. If a file was created by
branching, 'p4 annotate' includes the revisions of the
source file up to the branch point, just as 'p4 filelog -i'
does. If a file has history prior to being created by
branching (such as a file that was branched on top of a
deleted file), -i ignores those prior revisions and follows
the source. -i implies -c.
The -I flag follows all integrations into the file. If a
line was introduced into the file by a merge, the source of
the merge is displayed as the changelist that introduced the
line. If the source itself was the result of an integration,
that source is used instead, and so on. -I implies -c.
The -q flag suppresses the one-line header that is displayed
by default for each file. This flag does not affect tagged
output returned by a command. GetFileAnnotations runs in
tagged mode.
Annotate command options
Annotate command options
Flags for the fixes command.
No flags.
The -C flag lists only directories that fall within the
current client view.
Fixes command options
Fixes command options
Flags for the grep command.
No flags.
The -a flag searches all revisions within the specified
range. By default only the highest revision in the range
is searched.
The -i flag causes the pattern matching to be case-insensitive.
By default, matching is case-sensitive.
The -n flag displays the matching line number after the file
revision number. By default, matches are displayed as
revision#: <text>.
The -v flag displays files with non-matching lines.
The -t flag searches binary files. By default, only text files
are searched.
The -L flag displays the name of each selected file from which no
output would normally have been displayed. Scanning stops on the
first match.
The -l flag display the name of each selected file containing
matching text. Scanning stops on the first match.
The -s flag suppresses error messages that result from abandoning
files that have a maximum number of characters in a single line that
are greater than 4096. By default, an error is reported when grep
abandons such files.
The -F flag is used to interpret the pattern as a fixed string.
The -G flag is used to interpret the pattern as a regular expression.
Grep command options
Grep command options
Flags for the integrated command.
No flags.
The -r flag reverses the mappings in the branch view, swapping the
target files and source files. The -b branch flag is required.
Integrated command options
Integrated command options
Flags for the protects command.
No flags.
If the -a flag is specified, protection lines for all users are
displayed. If the -g group flag or -u user flag is specified,
protection lines for that group or user are displayed.
If the -m flag is given, a single word summary of the maximum
access level is reported. Note that this summary does not take
exclusions into account.
Protects command options
Protects command options
Flags for the reviews command.
No flags.
Reviews command options
Reviews command options
Flags for the triggers command.
No flags.
The -o flag writes the trigger table to the standard output.
The user's editor is not invoked.
The -i flag writes the trigger table from the standard input.
The user's editor is not invoked.
Triggers command options
Triggers command options
Flags for the typemap command.
No flags.
The -o flag writes the typemap table to the standard output.
The user's editor is not invoked.
The -i flag writes the typemap table from the standard input.
The user's editor is not invoked.
GetTypeMap command options
GetTypeMap command options
Flags for the protect command.
No flags.
The -o flag writes the protection table to the standard output.
The user's editor is not invoked.
The -i flag writes the protection table from the standard input.
The user's editor is not invoked.
protect command options
protect command options
Flags for the counter command.
No flags.
The -f flag sets or deletes counters used by Perforce, which are
listed by 'p4 help counters'. Important: Never set the 'change'
counter to a value that is lower than its current value.
The -d flag deletes counters used by Perforce, which are listed
by 'p4 help counters'. Important: Never set the 'change' counter
to a value that is lower than its current value. must be used with
-f.
The -i flag increments a counter by 1 and returns the new value.
This option is used instead of a value argument and can only be
used with numeric counters.
Counter command options
Counter command options
Flags for the describe command.
No flags.
The -d flag deletes the specified stream (unless the stream is
referenced by child streams or stream clients).
-dn RCS output.
-dc[n] context
-dc[n] context
-dc[n] context
-dc[n] context
-dc[n] context
The -s flag omits the diffs of files that were updated.
The -S flag lists files that are shelved for the specified changelist
and displays diffs of the files against their previous revision.
The -f flag forces display of the descriptions in a restricted
change. The -f flag requires 'admin' access, which is granted
using 'p4 protect'.
Options for the Describe command
Options for the Describe command
p4 help describe
describe -- Display a changelist description
p4 describe [-d<flags> -s -S -f] changelist# ...
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 indicated as 'pending' and file diffs are not displayed.
For restricted changelists, 'no permission' is displayed if the user
is not permitted to view the change (see 'p4 help change'). If a
submitted or shelved change is restricted, the description is hidden
unless the user is the owner of the change or has list permission for
at least one file in the change. To view restricted pending (not
shelved) changes, the user must be the owner of the change.
The -d<flags> passes one or more flags to the built-in diff routine
to modify the output: -dn (RCS), -dc[n] (context), -ds (summary),
-du[n] (unified), -db (ignore whitespace changes), -dw (ignore
whitespace), -dl (ignore line endings). The optional argument to
to -dc specifies number of context lines.
The -s flag omits the diffs of files that were updated.
The -S flag lists files that are shelved for the specified changelist
and displays diffs of the files against their previous revision.
The -f flag forces display of the descriptions in a restricted
change. The -f flag requires 'admin' access, which is granted
using 'p4 protect'.
Flags for the trust command.
No flags.
The -l flag lists existing known fingerprints.
The -y flag will cause prompts to be automatically accepted.
The -n flag will cause prompts to be automatically refused.
The -d flag will remove an existing trusted fingerprint of a connection.
The -f flag will force the replacement of a mismatched fingerprint.
The -i flag will allow a specific fingerprint to be installed.
The -r flag specifies that a replacement fingerprint is to be
affected. Replacement fingerprints can be used in anticipation
of a server replacing its key. If a replacement fingerprint
exists for a connection and the primary fingerprint does not match
while the replacement fingerprint does, the replacement fingerprint
will replace the primary. This flag can be combined with -l, -i,
or -d.
Options for the Trust command
Options for the Describe command
p4 trust -h
trust -- Establish trust of an SSL connection
p4 trust [ -l -y -n -d -f -r -i <fingerprint> ]
Establish trust of an SSL connection. This client command manages
the p4 trust file. This file contains fingerprints of the keys
received on ssl connections. When an SSL connection is made, this
file is examined to determine if the SSL connection has been used
before and if the key is the same as a previously seen key for that
connection. Establishing trust with a connection prevents undetected
communication interception (man-in-the-middle) attacks.
Most options are mutually exclusive. Only the -r and -f options
can be combined with the others.
The -l flag lists existing known fingerprints.
Without options, this command will make a connection to a server
and examine the key if present, if one cannot be found this command
will show a fingerprint and ask if this connection should be trusted.
If a fingerprint exists and does not match, an error that a possible
security problems exists will be displayed.
The -y flag will cause prompts to be automatically accepted.
The -n flag will cause prompts to be automatically refused.
The -d flag will remove an existing trusted fingerprint of a connection.
The -f flag will force the replacement of a mismatched fingerprint.
The -i flag will allow a specific fingerprint to be installed.
The -r flag specifies that a replacement fingerprint is to be
affected. Replacement fingerprints can be used in anticipation
of a server replacing its key. If a replacement fingerprint
exists for a connection and the primary fingerprint does not match
while the replacement fingerprint does, the replacement fingerprint
will replace the primary. This flag can be combined with -l, -i,
or -d.
Flags for the info command.
No flags.
The -s option produces 'short' output that omits any information
that requires a database lookup such as the client root).
Options for the Trust command
Options for the Describe command
p4 help info
info -- Display client/server information
p4 info [-s]
Info lists information about the current client (user name,
client name, applicable client root, client current directory,
and the client IP address) and some server information (server
IP address, server root, date, uptime, version and license data).
The -s option produces 'short' output that omits any information
that requires a database lookup such as the client root).
Describes the path and path type in a file spec.
Unescape a string.
Paths to unescape
Escape a string.
Path to escape
Escape a list of strings.
Path to escape
Escape an array of strings.
Paths to escape
Unescape a list of strings.
Perforce server
Unescape an array of strings.
Paths to unescape
A path spec in depot syntax.
A path spec in client syntax.
A path spec in local syntax.
The protection mode or rights associated with this entry.
The type of protection (user or group).
Describes a protection entry (line) in a Perforce protection table.
Specifies resource access privileges for Perforce users for a specific
Perforce repository.
The address of the Perforce server.
The Perforce server's version information.
The Perforce server's license information.
Defines useful metadata about a Perforce server.
Read the fields from the tagged output of an info command
Tagged output from the 'info' command
Defines the UTC offset for the server.
The current state of a specific server.
The server is offline.
The server is online.
The state of the server is unknown.
Represents a specific Perforce server.
The host:port used to connect to a Perforce server.
Note: this can be different than the value returned by the info
command if a proxy or broker is used to make the connection.
A stream specification in a Perforce repository.
Read the fields from the tagged output of a 'streams' command
Tagged output from the 'streams' command
Read the fields from the tagged output of a 'stream' command
Tagged output from the 'stream' command
Parse the fields from a stream specification
Text of the stream specification in server format
Format of a stream specification used to save a stream to the server
Convert to specification in server format
Defines the expected flow of change between a stream and its parent.
Development: Default. Direction of flow is
to parent stream with copy and from parent
stream with merge.
Mainline: May not have a parent.
Release: Direction of flow is to parent
with merge and from parent with copy.
Virtual: Not a stream but an alternative
view of its parent stream.
Task: A lightweight short-lived stream that
only promotes modified content to the
repository, branched data is stored in
shadow tables that are removed when the task
stream is deleted or unloaded.
Flags to configure stream behavior.
No flags.
Indicates whether all users or only the
of the stream may submit changes to the
stream path.
Indicates whether the stream spec is locked
against modifications. If locked, the spec
may not be deleted, and only its owner may
modify it.
Indicates whether integration from the
stream to its parent is expected to occur.
Indicates whether integration to the stream
from its parent is expected to occur.
Convert to a stream spec formatted string
Parse a client spec formatted string
No options.
Leaves all files writable on the client;
by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option.
Permits 'p4 sync' to overwrite writable
files on the client. noclobber is ignored if
allwrite is set.
Defines the case for the StringEnum.
No case defined.
Lowercase.
Uppercase.
Describes file submitted and file action performed.
Describes the results for a submit operation on one or more files.
Defines triggers on Perforce events.
Describes an individual entry in the trigger table.
Defines whent he trigger is to execute.
archive:
Execute an archive trigger for the server to access
any file with the +X filetype modifier.
service-check:
Execute an authentication check trigger to verify a
user's password against an external password manager
during login or when setting a new password.
auth-check-sso:
Facilitate a single sign-on user authentication. This
configuration requires two programs or scripts to run;
one on the client, the other on the server.
auth-set:
Execute an authentication set trigger to send a new
password to an external password manager.
change-submit:
Execute pre-submit trigger after changelist has been
created and files locked but prior to file transfer.
change-content:
Execute mid-submit trigger after file transfer but prior
to commit. Files can be accessed by the 'p4 diff2',
'p4 files', 'p4 fstat', and 'p4 print' commands using
the revision specification '@=change', where 'change' is
the pending changelist number passed as %changelist%.
change-commit:
Execute post-submit trigger after changelist commit.
fix-add:
Execute fix trigger prior to adding a fix. The special
variable %jobs% is available for expansion and must be
the last argument to the trigger as it expands to one
argument for each job listed on the 'p4 fix' command.
fix-delete:
Execute fix trigger prior to deleting a fix. The special
variable %jobs% is available for expansion and must be
the last argument to the trigger as it expands to one
argument for each job listed on the 'p4 fix -d' command.
form-out:
Execute form trigger on generation of form. Trigger may
modify form.
form-in:
Execute form trigger on input of form before its contents
are parsed and validated. Trigger may modify form.
form-save:
Execute form trigger prior to save of form after its
contents are parsed.
form-commit:
Execute form trigger after it has been committed, allowing
access to automatically generated fields (jobname, dates
etc). It cannot modify the form. This trigger for job
forms is run by 'p4 job' and 'p4 fix' (after the status
is updated), 'p4 change' (if the job is added or deleted)
and 'p4 submit' (if the job is associated with the change).
The 'form-commit' trigger has access to the new job name
created with 'p4 job', while the 'form-in' and 'form-save'
triggers are run before the job name is created. The
special variable %action% is available on the job
'form-commit' trigger command line, and is expanded when
the job is modified by a fix.
form-delete:
Execute form trigger prior to delete of form after its
contents are parsed.
shelve-submit:
Execute pre-shelve trigger after changelist has been
created but prior to file transfer.
shelve-commit:
Execute post-shelve trigger after files are shelved.
shelve-delete:
Execute shelve trigger prior to discarding shelved files.
Defines a Perforce repository's default mapping between
file names or locations and file types.
Describes an individual entry in the Perforce repository's typemap.
Defines the user type.
Standard: a normal user (licensed)
Service: a service user (not licensed)
Operator: an operator user (not licensed)
A user on a Perforce Server, represented by a P4 User spec.
p4 help user
user -- Create or edit a user specification
p4 user [-f] [name]
p4 user -d [-f] name
p4 user -o [name]
p4 user -i [-f]
Create a new user specification or edit an existing user specification.
The specification form is put into a temporary file and the editor
(configured by the environment variable $P4EDITOR) is invoked.
Normally, a user specification is created automatically the first
time that the user issues any command that updates the depot. The
'p4 user' command is typically used to edit the user's subscription
list for change review.
The user specification form contains the following fields:
User: The user name (read-only).
Email: The user's email address (Default: user@client).
Update: The date the specification was last modified (read-only).
Access: The date that the user last issued a client command.
FullName: The user's real name.
JobView: Selects jobs that are displayed when the user creates
a changelist. These jobs can be closed automatically
when the user submits the changelist. For a description
of jobview syntax, see 'p4 help jobview'
Reviews: The subscription list for change review. There is no
limit on the number of lines that this field can contain.
You can include the following wildcards:
... matches any characters including /
* matches any character except /
Password: The user's password. See 'p4 help passwd'.
Type: Must be 'service', operator, or 'standard'. Default is
'standard'. Once set, the user type cannot be changed.
The -d flag deletes the specified user (unless the user has files
open).
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
Read the fields from the tagged output of a user command
Tagged output from the 'user' command
Parse the fields from a user specification
Text of the user specification in server format
Format of a user specification used to save a user to the server
Convert to specification in server format
The user's user name.
The user's real name.
If set, user must have matching $P4PASSWD on client.
The user's email address; for email review.
The date this specification was last modified.
The date this user was last active. Read only.
Selects jobs for inclusion during changelist creation.
Listing of depot files to be reviewed by user.
Either 'service', 'operator', or 'standard'.
Default: 'standard'. Read only.
The specification for the user form
Identifies a specific revision or revision range of a Perforce managed SCM resource.
A revision range specifier consisting of a lower and upper revision.
A revision range specifier consisting of a lower and upper revision.
version spec to get lower revision
version spec to get upper revision
A revision range specifier consisting of a lower and upper revision.
int to get lower revision
int to get upper revision
ToString method for for VersionRange
String version range
Equals method for for VersionRange
object to get version range
True/False
Lower version revision.
Upper version revision.
A revision specifier #head.
ToString method for for HeadRevision
#head
Equals method for for HeadRevision
object to get head revision
True/False
A revision specifier #have.
ToString method for for HaveRevision
#have
Equals method for for HaveRevision
object to get have revision
True/False
A revision specifier #none.
ToString method for for NoneRevision
#none
Equals method for for NoneRevision
object to get none revision
True/False
A revision specifier that is a single revision.
A revision specifier that is a single revision.
ToString method for for Revision
String client revision version
Equals method for for Revision
object to get revision
True/False
A revision specifier that is a date and time.
The date/time.
The date/time.
ToString method for for DateTimeVersion
String date/time version
Equals method for for DateTimeVersion
object to get date/time
True/False
get Version as date/time
A revision specifier that is a label name.
The label.
ToString method for for LabelNameVersion
String label version
Equals method for for LabelNameVersion
object to get label
True/False
get Version as label
A revision specifier that is a changelist id.
The changelist.
ToString method for for ChangelistIdVersion
String changelist version
Equals method for for ChangelistIdVersion
object to get changelist
True/False
get Version as changelist
A revision specifier that is a client name.
The client name.///
ToString method for for ClientNameVersion
String client name version
Equals method for for ClientNameVersion
object to get client name
True/False
get Version as client name
A revision specifier that is a file action.
The file action.///
ToString method for for ActionVersion
String action version
Equals method for for ActionVersion
object to get action type
True/False
get Version as action
A revision specifier for a file that is shelved in a changelist id.
The changelist.
ToString method for for ChangelistIdVersion
String changelist version
Equals method for for ChangelistIdVersion
object to get changelist
True/False
get Version as changelist
Describes the mapping type.
A single entry in a view map.
Maps one or more Perforce file specs to zero, one, or more
other Perforce file specs.
Create an empty workspace view
Create a workspace view
List of Left/Right pairs for the map
Create a workspace view
Array of Left/Right pairs for the map
Split a single line from a view specification into left and right parts
Handles case where the left and/or the right string are enclosed
in quotes because they contain spaces. I.e "C:\my code\project 1\..."
Add a line to the end of the view
Left/Right pair for the map
Add a line to the end of the view
left side of mapping
right side of mapping
Convert to a Perforce server compatible string for a workspace spec
Augment String List used mostly for passing of parameters to command.
Default constructer
Construct a list with the specified capacity and preallocate the members
Create a list from a string array
Cast a string array to a string list
The list to cast
New StringList representing the results of the cast
Cast a StringList to a String[]
The StringList being cast
new String[]
Copy elements from another StringList into this list
The source StringList
The index of the first element copied in the destination array
How many elements to copy
Test to see if an object is equal to this StringLis. An object is
equal if it is a StringArray (or can be cast as one and has the
same elements in the same order.
object to test
true if equal
Override to quell compilation warning
Test to see if two StringList are equal. They are equal if they
have the same elements in the same order.
The first list
The second list
true if equal
Test to see if to StringList are different (not equal)
The first list
The second list
true if not equal
Convert the list to a single String. Each element is
separated by a /r/n line separator.
Add to string lists
The left list
The right list
A new list consisting of the elements of the left list followed by the elements of the right list
Test to see if the StringList is null or empty (has no elements)
The tagged output of a command.
Basic constrictor
Copy constructor
Source object
A list of tagged objects.
List of info messages.
Cast to a String[].
Cast to a String. Messages are separated by \r\n
A single line of output from an 'info' message.
The level of the message (0-9)
The level of the message (0-9)
The message
Create a new InfoLine
Level of the message
Message text.
Convert the info to text
String representation
Base class for objects returned by a command as 'tagged' data.
Contains a Hashtable of the field values for the object.
Derived object can provide properties to directly access
their standard attributes.
Default constructer
String that that is the field that identifies this object
The raw data returned from the server