Scion's ideas, with no server on one machine Las ideas de Scion, sin servidor en una sola máquina

Anthropic described Scion, its internal source control system, in Redesigning source control at Anthropic, published on 13 October 2026. These are the ideas braid takes from it: what the post says, and what braid does today.

Anthropic describió Scion, su sistema interno de control de versiones, en Redesigning source control at Anthropic, publicado el 13 de octubre de 2026. Estas son las ideas que braid toma de él: lo que dice el artículo y lo que braid hace hoy.

ChangesetsChangesetsformat v1

In the post: “a changeset stores a list of the files that changed relative to its first parent”.

In braid: the same. A changeset records the files that changed against its first parent, plus the root tree it produces, so history, blame and rebase read a short list while the root id still commits to the whole repository. Files, directories and changesets are immutable objects named by their BLAKE3 hash, and format v1, which fixes their bytes, is frozen.

En el artículo: un changeset guarda la lista de los ficheros que cambiaron respecto a su primer padre.

En braid: lo mismo. Un changeset registra los ficheros que cambiaron respecto a su primer padre, más el árbol raíz que resulta, así que la historia, blame y el rebase leen una lista corta y el id de la raíz sigue fijando el estado de todo el repositorio. Ficheros, directorios y changesets son objetos inmutables que se nombran por su hash BLAKE3, y el formato v1, que fija sus bytes, está congelado.

Landing in one short stepAterrizar en un paso cortobraid land

In the post: “A proper merge queue, for example, doesn’t make much sense at agent scale.” Instead of a global repository lock on the merge queue, Anthropic “invested in post-merge and pre-deploy automated testing”: concurrent changes can then conflict, and Claude typically fixes those conflicts. Moving a ref “is a compare-and-swap on a single Spanner row that happens separately from creating changesets”.

In braid: creating a changeset takes no repository lock, and landing it is one short step that the landings on a branch take in turn: a fast-forward, or a rebase path by path that merges only the files both sides touched, so the step costs what the change touches. On one machine, braid land takes it in the local store, in one op log transaction, and moves the branch with a compare-and-swap; on BraidHub, one task per branch takes it in order. The step runs no tests: as in the post, they run after landing, and braid verify, below, runs them on a branch's head. A landing that conflicts moves nothing and exits with status 2; with --json, each conflict gives its path, its kind and what each side has there. A branch never contains a conflict: the agent runs braid update, fixes the conflicts, commits and lands again.

En el artículo: una cola de fusión como es debido no tiene mucho sentido a la escala de los agentes. En vez de un cerrojo global del repositorio sobre la cola de fusión, Anthropic ha invertido en tests automáticos después de fusionar y antes de desplegar; los cambios simultáneos pueden entonces entrar en conflicto, y Claude suele arreglar esos conflictos. Mover una ref es un compare-and-swap sobre una sola fila de Spanner, aparte de crear changesets.

En braid: crear un changeset no bloquea el repositorio, y aterrizarlo es un paso corto que los aterrizajes en una rama dan por turnos: un fast-forward, o un rebase ruta a ruta que solo fusiona los ficheros que han tocado los dos lados, así que el paso cuesta lo que toca el cambio. En una sola máquina, braid land lo da en el almacén local, en una sola transacción del registro de operaciones, y mueve la rama con un compare-and-swap; en BraidHub, una tarea por rama lo da en orden. El paso no ejecuta tests: como en el artículo, los tests van después de aterrizar, y braid verify, más abajo, los ejecuta sobre la cabeza de una rama. Un aterrizaje con conflictos no mueve nada y sale con 2; con --json, cada conflicto da su ruta, su tipo y lo que tiene cada lado. Una rama nunca contiene un conflicto: el agente hace braid update, arregla los conflictos, hace commit y vuelve a aterrizar.

Objects any cache can serveObjetos que sirve cualquier caché

In the post: “the client talks over a socket to a daemon, scion-daemon, that stores objects for the whole node”; cache servers come next, and the authoritative scion-servers read from Spanner or cloud storage.

In braid: objects are immutable and named by id, so any tier can serve them, and braid's design gives a local store, a per-machine daemon, a cache and a server the same API. Today there are the local store and a first version of the server, BraidHub; the caches and the daemon are planned (milestones 6 and 7), and so is a virtual file system.

En el artículo: el cliente habla por un socket con un daemon, scion-daemon, que guarda los objetos de todo el nodo; después vienen servidores de caché, y los scion-servers, que son la autoridad, leen de Spanner o del almacenamiento en la nube.

En braid: los objetos son inmutables y se nombran por su id, así que cualquier nivel puede servirlos, y el diseño de braid da la misma API a un almacén local, a un daemon por máquina, a una caché y a un servidor. Hoy existen el almacén local y una primera versión del servidor, BraidHub; las cachés y el daemon están previstos (fases 6 y 7), igual que un sistema de ficheros virtual.

Bisect and revertBisección y reversiónbraid verify

In the post: every source control query that Scion's client uses is also exposed through an API, and “Many internal tools, such as our automated bisect and revert pipelines, wouldn’t be practical at scale without this cheap, programmatic access to source control.”

In braid: braid verify runs the project's tests on the head of a branch and keeps braid/green/<branch> at the newest changeset that passed. When they fail, it bisects the changesets since then to find the first that fails, and with --revert it reverts that one and lands the revert. It runs where you run it, as you: it is not a sandbox.

En el artículo: todas las consultas de control de versiones que usa el cliente de Scion están también en una API, y muchas herramientas internas, como sus procesos automáticos de bisección y reversión, no serían prácticas a gran escala sin ese acceso barato y programático al control de versiones.

En braid: braid verify ejecuta los tests del proyecto sobre la cabeza de una rama y mantiene braid/green/<rama> en el changeset más reciente que los pasó. Cuando fallan, busca por bisección, entre los changesets posteriores, el primero que falla y, con --revert, lo revierte y aterriza la reversión. Se ejecuta donde lo lances y con tus permisos: no es un sandbox.

Scion is built around a server: “Clients are always online,” the post says. Braid starts from one machine.

Scion gira en torno a un servidor: según el artículo, sus clientes están siempre conectados. Braid empieza por una sola máquina.

1. No server on one machine. In Scion, “every commit, rebase, or merge happens on the server, so there’s nothing to push”. In braid, the agents of one machine share one local store, each in a workspace of its own, and land on one main in turn. Many braid processes share that store: segments are leased with locks the kernel releases if a process dies, objects reach the disk before anything that refers to them, and an append-only op log records every change of a ref, so braid undo can step back. Agents on one machine commit, land and read history with no network. When agents on several machines share a repository, it lives on BraidHub, which is then the authority, as Scion's servers are, and braid land lands there with the output and exit statuses of a local landing. BraidHub is a first version: for anything that matters, keep a GitHub mirror as the source of truth.
2. Open source. Scion is “an in-house version control system”, and the post says “it’s difficult to offer Scion in a form that would be broadly useful to other organizations.” Braid is open source, under the Apache-2.0 license: anyone can read it, build it, run it and change it.
3. Git at the edges. Anthropic moved its monorepo from git to Scion, and of Scion the post says: “It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle”. Braid keeps git: braid git import brings in a git repository's whole history bit for bit: each commit is exported again as it is imported, and the import stops unless its id comes back the same. braid git sync keeps GitHub, Gitea or any git remote in step, and the remote only ever fast-forwards. In a clone where braid is not set up, agents work with git as before.

1. Sin servidor en una sola máquina. En Scion, todo commit, rebase o fusión ocurre en el servidor, así que no hay nada que subir con push. En braid, los agentes de una máquina comparten un único almacén local, cada uno en su propio espacio de trabajo, y aterrizan por turnos en un solo main. Muchos procesos de braid comparten ese almacén: los segmentos se reservan con cerrojos que el kernel libera si un proceso muere, los objetos llegan al disco antes que lo que apunta a ellos, y un registro de operaciones que solo crece apunta cada cambio de ref, para que braid undo pueda dar marcha atrás. Los agentes de una máquina hacen commit, aterrizan y leen la historia sin red. Cuando agentes de varias máquinas comparten un repositorio, este vive en BraidHub, que pasa a ser la autoridad, como los servidores de Scion, y braid land aterriza allí con la misma salida y los mismos códigos de salida que un aterrizaje local. BraidHub es una primera versión: para todo lo que importe, ten un espejo en GitHub como fuente de verdad.
2. Código abierto. Scion es un sistema de control de versiones interno, y el artículo dice que es difícil ofrecerlo de una forma que les sea útil a otras organizaciones en general. Braid es de código abierto, con licencia Apache-2.0: cualquiera puede leerlo, compilarlo, ejecutarlo y cambiarlo.
3. Git en los bordes. Anthropic pasó su monorepo de git a Scion, y el artículo dice que Scion se aparta tanto de git que una empresa tendría que migrar cada pieza de su ciclo de desarrollo. Braid se queda con git: braid git import trae toda la historia de un repositorio de git bit a bit: cada commit se vuelve a exportar al importarlo, y la importación se detiene si su id no sale idéntico. braid git sync mantiene al día GitHub, Gitea o cualquier remoto de git, y el remoto solo avanza en fast-forward. En un clon donde braid no está configurado, los agentes trabajan con git, como siempre.

Watch three agents land on one mainMira cómo aterrizan tres agentes en un solo main

The post names its own prior art: “Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling”. Of Sapling's server, Mononoke, it says: “It pioneered many of the techniques we use in Scion, in particular the Bonsai data model.” Braid owes the same work, and more:

El artículo cita sus propios precedentes: Piper, de Google, y Sapling, de Meta. Del servidor de Sapling, Mononoke, dice que fue pionero en muchas de las técnicas que usa Scion, en particular el modelo de datos Bonsai. Braid les debe lo mismo, y algo más:

• Mononoke, Sapling's server. A Bonsai changeset holds a flat list of the files a commit changed rather than a tree, and pushrebase rebases a push on the server when the branch has moved and the push touches other files, so that clients do not fetch, rebase and push again. Braid's changesets and its landing follow the same two ideas; its landing also merges a file both sides changed, and needs no server on one machine.
• Sapling: history served at scale, and compressing a file version against the previous one.
• Jujutsu: the operation log and undo. Jujutsu also records conflicts in commits; braid keeps them out of the branch and hands them back as data.
• gitoxide, for the git bridge, and the rest of the credits: BLAKE3, FastCDC, prolly trees and imara-diff.

• Mononoke, el servidor de Sapling. Un changeset de Bonsai guarda una lista plana de los ficheros que cambió un commit, en vez de un árbol, y pushrebase hace en el servidor el rebase de un push cuando la rama se ha movido y el push toca otros ficheros, para que los clientes no tengan que volver a hacer fetch, rebase y push. Los changesets de braid y su forma de aterrizar siguen esas dos ideas; además, al aterrizar, braid fusiona un fichero que han cambiado los dos lados, y en una sola máquina no necesita servidor.
• Sapling: servir historia a gran escala y comprimir cada versión de un fichero respecto a la anterior.
• Jujutsu: el registro de operaciones y el deshacer. Jujutsu además guarda los conflictos en los commits; braid los deja fuera de la rama y los devuelve como datos.
• gitoxide, por el puente con git, y el resto de los créditos: BLAKE3, FastCDC, los prolly trees e imara-diff.