Commit a pending changelist and the files it contains to the depot, and/or submit an open stream spec.
p4 [g-opts] submit [-r -s] [-f submitoption] -K [-b | --noretransfer 0|1] [--parallel=threads=N[,batch=N][,min=N]]
p4 [g-opts] submit [-r -s] [-f submitoption -K -b] [--parallel=threads=N[,batch=N][,min=N]] file
p4 [g-opts] submit [-r] [-f submitoption -K -b] [-So] -d description [--parallel=threads=N[,batch=N][,min=N]]
p4 [g-opts] submit [-r] [-f submitoption -K -b] [-Sx] -d description [--parallel=threads=N[,batch=N][,min=N]] file p4 [g-opts] submit [-r] [-f submitoption] -K [-b | --noretransfer 0|1] -c change [--parallel=threads=N[,batch=N[,min=N]]]
p4 [g-opts] submit -e shelvedchange -K [-b] [--parallel=threads=N[,batch=N][,min=N]]
p4 [g-opts] submit -i [--parallel=threads=N[,batch=N][,min=N]] p4 [g-opts] submit [-r -s] [-f submitoption -K -b] [--parallel=threads=N[,batch=N][,min=N]]
When a file has been opened by
integrate, the file is listed in a
changelist. The user’s changes to the file are made
only within the client workspace copy until the changelist is sent to the
In addition to the files being submitted, any open stream specification
is also submitted. To submit only files and not an open stream spec, see streams and p4 submit. For more information on open stream
By default, files are opened within the default changelist, but you can
also create new numbered changelists with
- To submit the default changelist, use
To submit a numbered changelist, use
p4 submit -c changelist.
-coption also allows you to change the description information for a numbered changelist.
By default, all files in the changelist are submitted to the depot, and
files open for
branch are closed when submitted, whether there are any
changes to the files or not. To change this default behavior, set the
SubmitOptions: field in the
p4 client form for your
workspace. To override your workspace’s
setting from the command line, use
p4 submit -f
When used with the default changelist,
brings up a form for editing in the editor defined by the
P4EDITOR) environment variable.
Files can be deleted from the changelist by deleting them from the form,
but these files will remain open in the next default changelist. To close
a file and remove it from all changelists, use
All changelists have a
Status: field. The value of this
changelists have been successfully submitted with
- Pending changelists have been created by the user but not yet been submitted successfully.
To supply a changelist description from the command line, use the
-d option. No change description dialog is presented. The
-d option works only with the default changelist, not with
A file’s location in the depot is determined by its location in the
local filesystem and by the client workspace definition, which is
specified in the
client form. See the "Configure clients" chapter in the
Helix Core Command-Line (P4) Guide.
p4 submit works atomically: either all the files
listed in the changelist are saved in the depot, or none of them are. The
atomic nature of
p4 submit allows files to be grouped
in a changelists according to their purpose. For example, a single
changelist might contain changes to three files that fix a single bug.
p4 submit fails if it is interrupted, or if any of
the files in the changelist are not found in the current client
workspace, are locked in another client workspace (with
p4 lock), or require
resolution and remain unresolved.
A progress indicator is available for
p4 submit if
you request it with
p4 -I submit.
Before committing a changelist,
p4 submit briefly
locks all files being submitted. If any file cannot be locked or
submitted, the files are left open in a numbered pending changelist. By
default, the files in a failed submit operation are left locked unless
submit.unlocklocked configurable is set. If
submit.unlocklocked is set, files are
unlocked even if they were manually locked prior to submit if submit
p4 submit fails while processing the default
changelist, the changelist is assigned the next number in the changelist
sequence, and the default changelist is emptied. The changelist that
failed submission must be resubmitted by number after the problems are
p4 submit fails, some or all of the files might
have been copied to the server. By default, retrying a failed submit
transfers all these files again unless the
submit.noretransfer configurable is set, in which case the
server attempts to detect if the files have already been transferred and
does not re-transfer all files when retrying a failed submit. You can use
--noretransfer option to override the
submit.noretransfer configurable and allow the user to
choose the preferred re-transfer behavior for the current submit
You can transfer files in parallel during the submit process. If there are sufficient resources, a submit command might execute more rapidly by transferring multiple files in parallel. For this feature to work, you must have both server and client upgraded to version 2015.2 or later. Read this section in its entirety to make sure that you are using this feature appropriately.
threads=to request that files be sent concurrently using the specified number of independent network connections. The threads grab work in batches.
You can specify
batch=to control the number of files in a batch.
You can specify the
minoption to control the minimum number of files in a parallel submit.
net.parallel.maxconfiguration variable is not set, the command executes without using parallel threads.
If the requested number of parallel threads exceeds the value set for
net.parallel.max, the command uses the maximum number of allowed threads.
Parallel submits from an edge server to a commit server use standard pull threads to transfer the files. The administrator must ensure that pull threads can be run on the commit server by doing the following:
- Make sure that the service user used by the commit server is logged into the edge server.
Make sure the
ExternalAddressfield of the edge server’s server spec is set to the address that will be used by the commit server’s pull threads to connect to the edge server.
If the commit and edge servers communicate on a network separate from the network used by clients to communicate with the edge server, the
ExternalAddressfield must specify the edge server ip address and port number that is used for connections from the commit server. Furthermore, the edge server must listen on the two (or more) networks.Important
Limitation: Parallel submit is not supported from an edge server if the commit server is on a Windows platform. In this case --parallel or automatic parallel processing for submit will be silently ignored, and the submit will run without using parallel threads.
--paralleloption is ignored when the archives are shared, for
p4 submit -e, and when progress indicators are used.
p4 configure set net.parallel.max=50
p4 configure set net.parallel.submit.threads=3
If automatic parallel processing is enabled, the following configurables no longer have the default value of
Configurable New value Description net.parallel.batch 8 for p4 sync, the number of files in a batch net.parallel.batchsize 512 KB for p4 sync, the number of bytes in a batch net.parallel.min 9 for p4 sync, the mininum number of files in a batch net.parallel.minsize 576 KB for p4 sync, the minimum of bytes in a parallel sync net.parallel.submit.batch 8 for p4 submit, number of files in a batch net.parallel.submit.min 9 for p4 submit, mininum number of files in a batch
In this case, you can use any of the syntax variants for the
p4 submitcommand (without specifying the
--paralleloption) and processing will be automatically done in parallel.
- If you do use the
--paralleloption explicitly and you have the
net.parallel.*configurables set, the configurable values you specify on the command line override the value of the configurables.
- You can turn off automatic parallel submit by unsetting the
- You can disable the parallel submit configurable settings by
p4 submit --parallel=0.
- If you do use the
Using parallel submits improves performance in cases like the following:
Significant network latency exists somewhere along the path through which the submitted file content travels from the client to the repository where the file content is stored.
This includes significant network latency between a Proxy and Server, or between an Edge Server and a Commit Server. When using parallel submit in such a configuration, the inherent TCP delays related to network latency occur concurrently, rather than sequentially when not using parallel submit.
Significant resources are required during the transfer of the submitted file, and those resources are available.
For example, if significant CPU cycles are required to compress ctext or binary file content as it is transferred from a client to a server, the compression of the file content can occur on one CPU core per parallel submit thread compressing either a ctext or binary file, so long as there are enough available CPU cores.
In other cases, using parallel submit might not result in significant performance benefits:
In some environments, network bandwidth can be a precious resource.
If network latency is minimal, it might not take many parallel submit threads to use the available network bandwidth. Once the available network bandwidth is used, adding parallel submit threads might not improve performance. This is especially true when transferring file content for which only network bandwidth resources are needed, such as when transferring ubinary files.
Using a small value for the
minarguments specified with the
--paralleloption is only practical in some cases.
For example, if a small number of large ctext or binary files are submitted using parallel submit, transferring a small number of files per parallel submit thread can result in the best performance, provided that adequate CPU and network bandwidth resources are available. For parallel submit to transfer an evenly-distributed number of files over the number of parallel submit threads specified (which defaults to
batchargument might need to be set to a value lower than its default of
For example, if submitting eight large ctext or binary files using four parallel submit threads, the
batchargument should be set to two. The value for the
minargument, which defaults to
9, should be set to less than or equal to the number of large ctext or binary files being submitted.
On the other hand, using a small value for the
batchargument can degrade performance when submitting many small files using parallel submit. In such a case, the overhead of the server frequently querying the
db.sendqtable for each batch by each parallel submit thread can result in
This feature is designed to reduce the amount of wait time end-users perceive when submitting files.
The -b option of the p4 submit command can be used on an edge server to enable the edge archive to be transferred to the commit server in the background. The submit process on the commit server schedules the transfers and completes the submit without the end user waiting for transfers to finish. The archives on the originating edge server are transferred to the commit server by pull threads initiated by submit on the commit server.
Submitting pending (not shelved) changes using the -b option causes any change-submit triggers to be fired before edge-content triggers (see Triggers and commit-edge). An administrator must ensure that pull threads can be run on the commit server. The edge server IP address and port number used by the commit server to connect to the edge server must be specified in the ExternalAddress: field of the edge server spec.
To learn how to enable this feature, see "Background archive transfer for edge server submits" in the Helix Core Server Administrator Guide.
If the administrator has not enabled background submit, the -b option is ignored and standard submit behavior occurs.
- Archives of ktext files are transferred serially because archive content depends on commit server work.
- This feature does not support graph depots.
Background archive transfer is incompatible with:
the command-line --noretransfer option
- the submit.noretransfer configurable
The -So option is to submit only the open stream spec.
By default, an open stream spec is not submitted and -Sx makes it explicit that only files are submitted.
The change number, or
Name of current client workspace.
Name of current Helix Server user.
The status is:
Textual description of changelist. This value must be changed.
A list of jobs that are fixed by this changelist. This field does not appear if there are no relevant jobs.
Any job that meets the jobview criteria as specified on the
Type of change:
A restricted shelved or committed changelist denies access to users who do not own the changelist and who do not have list An internal list indicates which files and revisions the client workspace has sync'd from the depot. See 'p4 have' in Helix Core Command-Line (P4) Reference. permission to at least one file in the changelist. A restricted pending (unshelved) changelist denies access to non-owners of the changelist. Public changes are displayed without these restrictions.
A list of files being submitted in this changelist. Files can be deleted from this list, but cannot be changed or added.
|See the section above, "About background archive transfer for edge server submits".
Submit changelist number
Changelists are assigned numbers either manually by the user
Immediately submit the default changelist (and the stream, if open) with the
Submit shelved changelist number
To submit a shelved change, all files in the shelved change must
be up-to-date and resolved. No files can be open in any workspace
at the same change number. The
This is the only submit option supported for files with propagating attributes from an edge server in a multi-server environment.
|Suppress keyword expansion when updating +k type files on the client. See File type modifiers.
Read a changelist specification from standard input. Input must
be in the same format as that used by the
Set to 1 to have the server avoid re-transferring files that have already been archived after a failed submit operation.
to 0 to have the server retransfer all files after a failed
submit operation. This setting overrides the setting of the
Specify options for parallel file transfer. The configurable
See Parallel processing .
Reopen files for
Allows jobs to be assigned arbitrary status values on submission
of the changelist, rather than the default status of
On new changelists, the fix status is displayed as the special
This option works in conjunction with the
A single parameter that can be a path with '…' as a wildcard.
This file pattern parameter can only be used when submitting the default changelist. The files in the default changelist that match the specified pattern are submitted. Files that don’t match the file pattern are moved to the next default changelist.
See Global options.
Submit only the only stream spec. No list of files allowed.
Excludes the open stream spec when submitting the specified list of files
|Can File Arguments Use Revision Specifier?
|Can File Arguments Use Revision Range?
|Minimal Access Level Required
|If submit.autobgtransfer is set,
p4 submit is an alias for
p4 submit -b
|Submit the default changelist, including the current open stream spec.
|p4 submit -c 4739
|Submit the numbered changelist, including the current open stream spec.
|p4 submit -So
|Submit only the open stream spec.
|p4 submit -Sx
|Submit the default changelist, but do not submit the open stream spec.
p4 submit foo bar
p4 submit -Sx foo bar
|Submit the specified changelist, but do not submit the open stream spec.
To create a new, numbered changelist
To open a file in a client workspace and list it in a changelist
To move a file from one changelist to another
To remove a file from all changelists, reverting it to its previous state
To view a list of changelists that meet particular criteria
To read a full description of a particular changelist
To read files from the depot into the client workspace
To edit the mappings between files in the client workspace and files in the depot