How it works

Your files stay on your machine.The history lives on the server.

Three ideas do most of the work: a working copy you edit, one server that decides what's history, and files that travel in chunks.

01 / Shared history

The server has the final word.

You edit files in your working copy. Submit sends a change to the server; sync brings accepted changes to everyone else.

Your working copyThe files you edit

submit

The serverAccepted history

sync

A teammate’s working copyVerified content

The server acknowledges a submit only after the change is safely on disk. That promise is only as good as your storage's flush, so choose your disks accordingly.

Durability and recovery

02 / Content transfer

A 2 GB file with a small change
is usually a small upload.

Scribe splits files at content-defined boundaries and names each chunk by its hash. Before uploading, it asks which chunks the server is missing.

On sync, chunks already on your disk are reused and only the rest is fetched. Every rebuilt file is verified before you get it.

Inside the transfer path

World.sceneAn eight-chunk illustration

Choose which chunks to change.

2new chunks to upload

6chunks already on the server

This example assumes the server has the original chunks and none of the new ones. Actual chunk boundaries and transfer size depend on the data. This is an illustration, not a benchmark.

03 / Branching

Try the snow biome on a branch.
Without copying the desert.

A new branch copies metadata and shares the asset content that already exists. Trying a new environment doesn't duplicate every file.

Merges compare against a common ancestor. Text edits that don't overlap merge on their own; binary conflicts need your call. Locks apply across branches.

Branches and conflict resolution

mainbiome/snow

Shared asset contentDesert.scene · Sand.material

Branches have their own history and share object content.

04 / Your setup