Copy submitted files in your local server to a remote server.

p4 [g-opts] push [-n -v] [-r remotespec] [-S stream | filespec]

The p4 push command takes the specified set of files, and the changelists which submitted those files, and copies them to the specified remote server.

A push is only allowed if the files being pushed fit cleanly into the remote server, building precisely on a shared common history. If there are any conflicts or gaps, the push is rejected. Otherwise, the changelists become new submitted changelists in the remote server.

When the changelists are added to the remote server, they are given newly assigned change numbers but they retain the same description, user, date, type, workspace, and set of files.

When the files are added to the remote server, they are kept in their same changelists, as new revisions starting after the current head. The new revisions retain the same revision number, file type, action, date, timestamp, digest, and file size.

Although the changelists are new submitted changelists in the remote server, none of the submit triggers are run in the remote server.

Typically, the p4 push command specifies a remote spec, and the DepotMap field in the remote spec specifies which files are to be pushed. The p4 push command may also specify a filespec argument to further restrict the files to be pushed. If the remote spec uses differing patterns for the local and remote sides of the DepotMap, the filespec argument, if provided, must specify the files using the local filename syntax.

If a particular changelist includes some files that match the filespec, and other files that do not, then only the matching files are included in the push. In order to ensure that a partial changelist is not pushed, an appropriate filespec should be specified (e.g., //...@change,#head).

In addition to the file revisions and the changelists, the p4 push command also copies the archive content to the remote server. In the case of lazy copies, the remote server may already have the corresponding archive, in which case the lazy copy is adjusted to reference the remote server's existing archives.

The p4 push command also copies all integration records which describe integrations to the files being pushed. These integration records are adjusted in the remote server to reflect the resulting changelist numbers and revision numbers of the remote server.

In order to push a set of files, you must have read access to those files in the current server, and you must have write access to those same files in the remote server (according to the remote server's protections table); your local userid is also used as the userid at the remote server and you must already be logged in to both servers prior to running the p4 push command.

The p4 push command is atomic: either all the specified files are pushed, or none of them are pushed.

If the -r option is not specified, p4 push pushes files to the remote server named origin.

By default, changes cannot be pushed from server to server; in order to push changes between servers, an administrator of each server must enable pushing. Set server.allowpush to 1 on the server which initiates the push; set server.allowpush to 2 on the destination server. Files with the filetype modifiers +k, +l, or +S have some special considerations. Files of type +k have their digests cleared when pushed. This means certain cross-server merge conflicts are not detected. To re-generate the digests in the remote server after the push, use p4 verify.

When pushing files of type +l, the new files are added to the remote server even if the files are currently open by a pending changelist in that server. When pushing files of type +S, old archives which exceed the specified limit are not purged by the p4 push command.