Click or drag to resize

ClientSubmitFiles Method

Namespace:  Perforce.P4
Assembly:  p4api.net (in p4api.net.dll) Version: 2023.2.255.3501
Syntax
public SubmitResults SubmitFiles(
	Options options,
	FileSpec file
)

Parameters

options
Type: Perforce.P4Options
file
Type: Perforce.P4FileSpec
Optional file to submit

Return Value

Type: SubmitResults
Remarks

p4 help submit

submit -- Submit open files to the depot

p4 submit [-r -s -f option --noretransfer 0|1]
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 --noretransfer 0|1] -c changelist#
p4 submit -e shelvedChange#
p4 submit -i [-r -s -f option]
--parallel=threads=N[,batch=N][,min=N]

'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. By default, the files in
a failed submit operation are left locked unless the
submit.unlocklocked configurable is set. Files are unlocked even if
they were manually locked prior to submit if submit fails when
submit.unlocklocked is set. '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.

If submit fails, some or all of the files may have been copied to
the server. By default, retrying a failed submit will transfer all of
the files again unless the submit.noretransfer configurable is set.
If submit.noretransfer is set to 1, submit uses digest comparisons to
to detect if the files have already been transferred in order to
avoid file re-transfer when retrying a failed submit.

The --noretransfer flag is used to override the submit.noretransfer
configurable so the user can choose his preferred re-transfer
behavior during the current submit operation.

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 -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. 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.

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.

The --parallel flag specifies options for parallel file transfer. If
parallel file transfer has been enabled by setting the
net.parallel.max configurable, and if there are sufficient resources
across the system, a submit command may execute more rapidly by
transferring multiple files in parallel. Specify threads=N to request
files be sent concurrently, using N independent network connections.
The N threads grab work in batches; specify batch=N to control the
number of files in a batch. A submit that is too small will not
initiate parallel file transfers; specify min=N to control the
minimum number of files in a parallel submit. Requesting progress
indicators causes the --parallel flag to be ignored.

Using --parallel from an edge server allows parallel file transfer
from the edge server to the commit server. This uses standard pull
threads to transfer the files. Note that an adminstrator must insure
that pull threads can be run on the commit server. The address
used by the commit server to connect to the edge server must
be specified in the ExternalAddress field of the edge server spec.

Only 'submit -e' is supported for files with propagating attributes
from an edge server in a distributed environment.

See Also