Fetching and Pushing

Fetching and pushing 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 fetching and pushing to copy changelists between shared servers.

Fetch and push are to the distributed versioning model what sync and submit are to classic Helix’s central server model.

The p4 fetch command copies the specified set of files and their history from a remote server into a local server. The p4 push command copies the specified set of files, and their history from a local server to a remote server. Both commands are atomic: either all the specified files are fetched or pushed or none of them are.

If a p4 push command fails after it has begun transferring files to the remote server, it will leave those files locked on the remote server. The p4 opened command will display locked, and the files cannot be submitted by any other user. If the p4 push command cannot be quickly retried, you can use the p4 unlock -r command to unlock the files on the remote server.

The p4 push command is not allowed if there are unsubmitted changes in the server from which you’re pushing; use p4 resubmit to resubmit those changes first, or discard the shelves with p4 shelve -d if they are not wanted. For more information on p4 unsubmit and p4 resubmit, see “Rewriting History”.

To monitor the progress of the fetch or push, pass the -I option to the command: 

$ p4 -I fetch
$ p4 -I 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 RemoteUser field in the remote server’s remote spec.
  • 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 on (they’re off by default) on both the remote server and the local server. See the command p4 help configurables for more information.
  • The user must be logged into the remote server via p4 login -r.