Workflows and partial replicas#

Centralized workflow#

Unlike distributed systems that require a full local clone of the repository, Unity Version Control (UVCS) allows you to connect a local workspace directly to the central server. This workflow has the following advantages:

• You can check out only the files you need.
• You send commits directly to the central server.
• You don't need a local copy of the repository, and can save disk space.

This workflow can be helpful for artists or other team members that don’t require the full version history.

Distributed workflow#

If you prefer a distributed workflow with a local repository, Unity Version Control (UVCS) provides features to manage repository size. For example, you can use nodata replicas, or xlinks.

Nodata replicas#

To manage repository size in a distributed workflow, you can create a nodata replica of the repository. A nodata replica is a clone that contains all the repository's metadata but none of its actual file data (blobs):

• Metadata includes all changesets, branches, labels, and permissions.
• Data refers to the actual content of the files (blobs).

This setup results in a very small local repository.

When you access a file, the data is retrieved on-demand from the server. You can browse history, diff files, and change branches without locally stored file data. Any new checkins you create add data to your local repository. You can then push the checkins to the central server.

For more information on how to create and manage nodata replicas, refer to Use a nodata replica.

Hydrating replicas for offline work#

A nodata replica needs a connection to the central server to fetch file data. With the hydrate command, you can selectively download data for offline use.

Hydrating is the process that occurs when you download the actual file data from the original server and store it in your local nodata replica. A common workflow is to create a nodata replica of the main branch and hydrate only the latest changeset. This workflow provides a complete working copy for development without downloading the data for the entire project history.

For more information on how to hydrate a nodata replica, refer to Hydrate a replica for offline use.

Use Xlinks to structure projects#

UVCS supports Xlinks, which allow you to split a large project into several smaller, more manageable repositories. For example, you can fully replicate the code repository with data for main development, while using a nodata replica for a large art asset repository. Alternatively, you can use an Xlink that points directly to a centralized art repository to avoid needing a local clone of the repository entirely.