Understanding Remotes
A remote describes how depot files are mapped between a personal server
and a shared server. A remote spec — which describes a remote — is
created by the user and has a unique name. A remote is used with the
p4 push
, p4 fetch
, and
p4 clone
commands to describe source and target
directories. The following picture illustrates mapping depot files
between a personal and a shared server:
As depicted in the figure above, a remote holds file mappings between depot paths on the shared server and depot paths on the personal server.
- For fetch and clone operations, it defines the files from the remote server that you want in your personal server and specifies where you want them to reside.
- For a push operation, it defines the files from the personal server that you want in the shared server and specifies where you want them to reside.
Remotes provide a convenient way to give you the exact files you need to
work on a particular project. You can simply clone from a shared server,
specifying the remote id of the remote that maps the desired files. These
files are then copied to your personal server. Once they’ve cloned, you
can use p4 fetch
to refresh the files initially
obtained with the p4 clone
command. Over time, you
can edit remote specs to account for:
- the addition of new streams, or
- the removal of old streams.
Using remotes allows you to fetch a subset of all the files on the shared server. This is in contrast to other distributed versioning systems, such as Git, which require that you fetch all files.
Note that when you clone a set of files from a shared server by
specifying a remote,
Helix Server
creates a new remote named origin
and copies the remote into
your local system. Future invocations of p4 fetch
do
not need to pass in -r
remote, as origin
is now
assumed to be the remote.
There are two different scenarios in which remotes are created:
- You create a remote on a shared server so that other users can clone
from this server and obtain the files they need to work on a project.
Note that to create a remote on a shared server, you must have an
access privilege of
open
or greater. While this task typically falls in the domain of an administrator, it does not require administrator privileges. - You — an individual user — create one or more remotes on your personal server so that you can eventually push your work to and fetch files from one or more shared servers.
You would create a remote on a shared server to dictate which subset of
the shared server’s repository a personal server retrieves when it clones
from the shared server. After cloning, you use the origin
remote on your personal server. You can then either edit the
origin
remote or create a different remote to control which
streams the personal server fetches and pushes when using that
remote.
Also in this section: