Fetching and pushing lie at the heart of a collaborative distributed workflow; they enable users to perform two major tasks:

Fetch and push also allow shared servers to exchange files and history with each other, transferring between servers both changelists and versioned file content.

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 shared server into a personal server. The p4 push command copies the specified set of files, and their history from a personal server to a shared 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 shared server, it will leave those files locked on the shared 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 shared 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