P4V Documentation | 2025.1

# Fetch and push

Fetch and `Push` lie support a collaborative distributed workflow and enable users:

- 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 Core 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 can 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 fetch and push

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

## Fetch and Push copy metadata

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 metadata The data stored by Helix Core Server that describes the file revisions in the depot, where they get their content from (see lazy copy), and the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the archive files that users submit.:

- 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

Zipping and unzipping files also copies attributes and fix records.

Your search for returned results