Understanding remote mappings

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 Push, Fetch, and Clone to describe source and target directories.

The following picture illustrates mapping depot files between a personal and a shared server:

remote map

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.

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 Fetch to refresh the files initially obtained with Clone.

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. This remote will be used for all future fetches.

There are two different scenarios in which remotes are created:

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.