How Vsync works

You only need a few concepts to use Vsync effectively.

Builds

A build is an immutable snapshot of a directory, registered into a game. Each build has a short ID like #42, and can also carry a human-readable version, source revision, build configuration, notes, and status flags.

Under the hood the snapshot's bytes are addressed by a content ID derived from the directory's contents, so identical directories transfer nothing twice - even when several builds are registered from the same contents.

Games and platforms

One server can host several games. Each build belongs to one game and one platform. Platforms are a fixed set: win64, linux, macos, ps4, ps5, xboxone, xsx, and switch.

Streams

A stream is a named line of builds within a game, such as nightly, release, or qa. You create it before it can be used, and a build joins it when it is committed - each build belongs to one stream, or to none.

A stream spans platforms: its tip for a platform is simply the newest build of that platform in it. Fetching a stream gets that tip; fetching a build ID always gets that exact immutable build.

Deleting a stream asks what to do with its builds: keep them (they leave the stream and age out under the normal retention rules) or delete them with it.

Cache and checkouts

The local cache stores chunks and manifests that can be reused by future builds. A checkout is a normal directory containing a materialized build that you can run, copy, or inspect.

Deleting cached chunks does not delete checkouts. Deleting a checkout does not necessarily remove its chunks from the cache.

Deduplication

Before transferring a build, Vsync asks which chunks the destination already has. Only missing chunks cross the network. Updating a checkout is staged and then swapped into place, so cancellation or failure leaves the previous build intact.