Fetch and push

Fetch and Push lie at the heart of a collaborative distributed workflow; they enable users to perform a number of major tasks:

• To copy changelists from a personal server to a shared server
• To fetch changelists from a shared server that were pushed there by other personal servers
• To obtain and work with a subset of a shared server’s entire repository.
• To copy work between two personal servers

Administrators can also use Fetch and Push to copy changelists between shared servers.

Fetch and Push are to the distributed versioning model what sync and submit are to the classic Helix Server central server model.

Fetch copies the specified set of files and their history from a remote server into a personal server. Push copies the specified set of files and their history from a local server to a remote server. Both are atomic: either all the specified files are fetched or pushed or none of them are.

If Push fails after it has begun transferring files to the remote server, it will leave those files locked on the remote server. The files cannot be submitted by any other user. If Push cannot be quickly retried, you can connect to the remote server with another P4V window to manually unlock the affected files.

When a DVCS repository is made via Clone or Init, the files in the repository (whether cloned, or fetched from a remote) default to allwrite mode. This means the files may be edited without checking them out.

If a file has been changed in allwrite mode, P4V treats it like an "offline edit" and will automatically reconcile the change before running Fetch or Push. This means that the changes are submitted to the repository before the Fetch or Push.

However, a file which is in a pending changelist (that hasn’t been submitted) must be submitted before running Fetch or Push. If files are shelved, they should be unshelved and submitted, or deleted before running Fetch or Push.

Configure security for fetching and pushing

In order to Fetch and Push between servers, the respective servers must have authentication and access permissions configured correctly:

• The user name on the remote server must be the same as the user name on the local server. This will be the case by default unless you have specified the Remote User field in the remote server’s remote mapping.
• The user must exist on the remote server.
• The user must have read (Fetch) and write (Push) permission on the remote server.
• The server.allowpush and server.allowfetch configuration settings must be set to 1, 2, or 3 on both the remote server and the personal server.

Specify what to copy

If the local and remote sides of the Depot Map pattern is modified to map differently within the Remote Map, and a filespec or stream name is provided, then the filespec argument or stream name must be specified using the personal server’s depot syntax. The filespec must always use depot syntax, not file system or client syntax. For more information, see Understanding remote mappings.

What do Fetch and Push copy?

In addition to the specified set of files, the changelists that submitted those files, and integration records, fetching and pushing to a server also copies the following:

• attributes
• any fixes associated with the changelists, but only if the job that is linked by the fix is already present in the local server