p4 fetch

Copy files from a remote server into your local server.

Syntax

p4 [g-opts] fetch [-r remotespec] [-m depth] [-v -k] [-n | -t] [-Ox] 
                  [-S stream | FileSpec[revSpec]
p4 [g-opts] fetch [-r remotespec] [-v] [-n] [-Ox] -s shelf

Syntax conventions

Description

(DVCS) The p4 fetch command copies the following items from the specified remote server to the local server:

• the specified set of files, which can involve a specified revision range
• the changelists that submitted those files
• the files' 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. If it is not, then the fix is not copied.
• all integration records that describe integrations to the files being fetched

A fetch is only allowed if the files being fetched fit cleanly into the server to which you’re currently connected, building cleanly on a shared common history.

The second form of the command copies a shelved changelist, rather than one or more submitted changelists, in which case conflicts do not arise. The result is a new shelved change in the local server.

If there are no conflicts, the files and their changelists become new submitted changelists in the local server. Conflict handling is configurable, using the -t option. If -t is not specified, and there are any conflicts or gaps, the fetch is rejected. The -t option specifies that the conflicting changelists should be relocated to the tangent depot, and the remote work is then fetched. After the fetch completes, use p4 resubmit to resubmit the conflicting local changes.

When the changelists are added to the local 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 local 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 local server, none of the submit triggers are run in the local server.

Typically, the p4 fetch command specifies a remote spec, and the DepotMap field in the remote spec specifies which files are to be fetched. The p4 fetch command can also specify a filespec argument to further restrict the files to be fetched. The filespec argument can be one of the following:

• the name of a stream, such as -S dev
• a filename pattern, such as //stream/dev/..., //path1/..., or //...

You cannot not specify both a stream and a filename pattern in a single fetch command.

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, only the matching files are included in the fetch. To ensure that a partial changelist is not fetched, an appropriate filespec should be specified (for example, //...@change,#head).

p4 fetch behaves differently if the remote spec’s ArchiveLimits: field is set. This field regulates how many, if any, revisions of file archives are stored on the server you fetch to. For more information, see the section "Configure server to limit storage of archive revisions" in the "Fetching and Pushing" chapter of Using Helix Core Server for Distributed Versioning.

When p4 fetch copies integration records, they are adjusted in the local server to reflect the resulting changelist numbers and revision numbers of the local server. In order to fetch a set of files, you must have read access to those files in the remote server, and you must have write access to those same files in the local server; your local userid is used as the userid at the remote server and you must already be logged in to both servers prior to running the p4 fetch command.

By default, a server does not accept fetch requests from another server. To fetch from a server, an administrator of that server must enable fetching by setting server.allowfetch to 1.

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

Files with the filetype modifiers +k, +l, or +S have some special considerations. Files of type +k have their digests cleared when fetched. This means certain cross-server merge conflicts are not detected. To re-generate the digests after the fetch, use the p4 verify command. When fetching files of type +l, the new files are added to the server even if the files are currently open by a pending changelist in the server. When fetching files of type +S, old archives which exceed the specified limit are not purged by the fetch command.

The value of the rpl.checksum.change configurable determines the level of verification performed for the p4 fetch command. See Configurables.

Triggering on fetches

The following push trigger types may be invoked during the execution of the p4 fetch command:

• The push-submit trigger can customize processing during the phase of the p4 fetch command when metadata has been transferred but files have not yet been transferred.
• The push-content trigger can customize processing during that phase of the p4 fetch command when files have been transferred but their contents have not yet been committed.
• The push-commit trigger can do any clean up work or other post processing after changes have been committed by the p4 fetch command.

For more information, see the section "Triggering on pushes and fetches" in the scripting chapter of Helix Core Server Administrator Guide.

Options

With no options specified p4 fetch fetches files from the remote server named origin.

-k	Suppresses automatic sync of workspace to the head revision.
-m depth	Specifies that Helix Server should perform a shallow fetch; only the last number of revisions specified in depth are fetched.
-n	Performs correctness checks but does not fetch any files or changelists from the remote server. In particular, Helix Server checks for conflicts between work that’s been done in the local server and work you are trying to fetch from the remote server. This tells you whether your personal server is up to date with the remote server.
-Oc	When set, the p4 fetch command outputs information about every changelist. The -v option must be set for this to take effect.
-Of	When set, the p4 fetch command outputs information about every file in every changelist. The -v option must be set for this to take effect.
-Oi	When set, the p4 fetch command outputs information about every integration in every file in every changelist. The -v option must be set for this to take effect.
-r remotespec	Specifies a remote spec containing the address of the remote server, and a file mapping which is to be used to re-map the files when they are fetched from the remote server. See also p4 remote.
--remote-user	Can be used to specify the username for the target server, overriding any RemoteUser field in the remote spec. (See p4 remote)
-s	Specifies a shelved changelist to be fetched, instead of one or more submitted changelists.For more information, see the section "Fetch and push a shelved changelist" in the "Fetching and Pushing" chapter of Using Helix Core Server for Distributed Versioning.
-t	Specifies that conflicting changelists should be relocated to the tangent depot, automatically creating that depot if it does not exist. The relocated changes can then be resubmitted using p4 resubmit. If you don’t specify a remote server with the -r option, the remote server defaults to origin. Note p4 fetch -t requires admin permission.
-S stream	Specifies a particular stream to fetch. If you specify a stream you cannot also specify a file or files.
-v	Enables verbose mode, which provides diagnostics for debugging. With verbose mode enabled, you can refine and control the precise level of verbosity. Specifically, you can indicate whether you want information about: every changelist fetched (with the -Oc option) every file in every changelist fetched (with the -Of option) every integration of every file in every changelist fetched (with the -Oi option) You can specify any combination of these options, but must always include the -O. The default is to display information about every changelist.
FileSpec[revSpec]	Specifies which files (and optionally which revisions) to fetch. If you specify files, you cannot specify a stream with the -S option.

Usage Notes

Can File Arguments Use Revision Specifier?	Can File Arguments Use Revision Range?	Minimal Access Level Required
N/A	N/A	read on the remote server, write on the local server.

Examples

p4 fetch -m 5 -r dev	Fetch the most recent 5 revisions of each file in the dev remote spec.
p4 fetch -r 1777-a //...@3,@6	Fetch all files with revisions in the range of 3 to 6

Related Commands

To push to a remote server

p4 push