Send only the missing pieces
Big files, smaller uploads.
Change part of an asset and Scribe uploads only the chunks the server doesn't have yet.
How transfers workWhy Scribe
Games are made by a lot of peopletouching the same files.
Artists, designers, and programmers end up in one repository, with very different files and very different patience for version control. Scribe keeps one history for all of it.
One change, start to finish
From a terrain tweak in the editor
to the next person's starting point.
- World.sceneWho has which version
- YouEdited, not submitted yet
- ServerRevision 41
- TeammateRevision 41
01Do the work.
Reshape the valley in your editor, in your own working copy. Nothing leaves your machine yet.
- World.sceneWho has which version
- YouSubmitted
- ServerRevision 42, safely on disk
- TeammateStill on revision 41
02Submit it.
The server writes the change to disk first and says yes second. Never the other way around.
- World.sceneWho has which version
- YouRevision 42
- ServerRevision 42
- TeammateRevision 42, plus new trees
03Someone picks it up.
A teammate syncs, gets verified files, and carries on from your valley.
An illustrated team workflow. See how it works
World.scenePlayer.rsTerrain.mat
One history for the whole project.Art and code, one history.
Branches give new ideas room. Locks stop two people quietly editing the same file that can't be merged.
Branches and locksWorld.scene local edits.scribe/recovery saved before replacement
Your work has a way backSync saves before it replaces.
Before sync overwrites a file you changed, it copies it to recovery. Files you've opened for editing wait.
Local-work protectionIs it for you?
Scribe fits best when
- most of the repository is large binaries, with code alongside.
- you want the history on machines you operate.
- people coordinate edits and each syncs only their part.