Copy files from a remote server into your local server.
For distributed version control. See Using Helix Core Server for Distributed Versioning (DVCS).
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
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.
-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.
If a particular revision of a file has been copied from ServerA to
a local ServerB and ServerC, changing the attributes on that revision on the local ServerB by using
p4 attribute -f only affect the revision on ServerB.
When changes are pushed or fetched, the Type: field for changes ignores the setting of the defaultChangeType configurable on the target server.
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 you use a filespec argument to restrict the files to be fetched, the LastFetch: field will not be updated until you issue p4 fetch without a filespec argument .
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,
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.
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
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
p4 fetch command is atomic: either all the
specified files are fetched, or none of them are fetched.
Files with the filetype modifiers
+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
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.
p4 fetch automatically performs a
p4 sync as part of its
The following push trigger types may be invoked during the execution of
p4 fetch command:
push-submittrigger can customize processing during the phase of the
p4 fetchcommand when metadata has been transferred but files have not yet been transferred.
push-contenttrigger can customize processing during that phase of the
p4 fetchcommand when files have been transferred but their contents have not yet been committed.
push-committrigger can do any clean up work or other post processing after changes have been committed by the
With no options specified
p4 fetch fetches files
from the remote server named origin.
Suppresses automatic sync of workspace to the head revision.
Specifies that Helix Server should perform a shallow fetch; only the last number of revisions specified in depth are fetched.
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.
When set, the
When set, the
When set, the
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
|--remote-user||Can be used to specify the username for the target server, overriding any RemoteUser field in the remote spec. (See p4 remote)|
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.
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 fetch -t requires
Specifies a particular stream to fetch. If you specify a stream you cannot also specify a file or files.
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:
You can specify any combination of these options, but must
always include the
The default is to display information about every changelist.
Specifies which files (and optionally which revisions) to fetch. If you specify files,
you cannot specify a stream with the
|Can File Arguments Use Revision Specifier?||Can File Arguments Use Revision Range?||Minimal Access Level Required|
read on the remote server,
Fetch the most recent
||Fetch all files with revisions in the range of
To push to a remote server