p4 fetch
Synopsis
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
]
p4 [g-opts
] fetch [-r
remotespec
] [-v] [-n]
[-Ox
] -s
shelf
Description
The p4 fetch
command copies the following items from the
specified remote server to the local server:
- the specified set of files
- 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.
Note that once a particular revision has been copied to a local server,
using p4 attribute -f
to change the attributes on that revision
will only affect the revision on that server, not on any other server to
which it may have been copied.
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 may also specify a filespec
argument to further restrict the files to be fetched. 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, then
only the matching files are included in the fetch. In order 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 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.
In order to fetch from a server, an administrator of that server must
enable fetching by setting server.allowpush
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”.
Note
p4 fetch
automatically performs a p4 sync
as
part of its operations.
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 thep4 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 thep4 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 thep4 fetch
command.
For more information, see the section "Triggering on pushes and fetches" in the scripting chapter of Helix Versioning Engine Administrator Guide: Fundamentals.
Options
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 Perforce 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, Perforce checks for conflicts between work that’s been done in the local server and working you’re 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 The |
|
When set, the The |
|
When set, the 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 |
|
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 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 Note
|
|
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 to fetch. If you specify a file or files you
cannot specify a stream with the |
Usage Notes
Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
---|---|---|
N/A |
N/A |
|
Examples
|
Fetch the most recent |