Fetch and Push
lie at the heart
of a collaborative distributed workflow; they enable users to perform a
number of major tasks:
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 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 may 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
.
In order to Fetch
and Push
between servers, the respective servers must have authentication and
access permissions configured correctly:
Remote User
field in the remote server’s
remote mapping.Fetch
) and
write (Push
) permission on the remote
server.server.allowpush
and server.allowfetch
configuration settings must be set to On (they are Off by default) on
both the remote server and the personal server.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 Understanding remote mappings.
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:
Zipping and unzipping files also copies attributes and fix records.