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 Userfield 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.allowpushandserver.allowfetchconfiguration settings must be set to1, 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.
