- Lore, mantenido por Epic Games, es un sistema de control de versiones de código abierto de próxima generación orientado a proyectos que manejan código y grandes recursos binarios al mismo tiempo
- Puede empezar rápidamente en local y luego escalar según sea necesario, y soporta grandes repositorios y equipos mediante datos compartidos y reutilizables junto con descargas en el momento necesario
- Usa un repositorio centralizado basado en direccionamiento por contenido, y representa el estado del repositorio y el historial de cambios con un árbol de Merkle y una cadena de revisiones inmutable
- Los archivos grandes se almacenan como chunks reutilizables, y con sparse workspace y on-demand hydration no hace falta descargar todos los datos desde el inicio
- Se publicó bajo licencia MIT y ofrece CLI, API para C/C++, C#, Rust, Go, Python y JavaScript, además de varios repositorios SDK
Control de versiones para manejar código y grandes recursos juntos
- Lore es un sistema de control de versiones de código abierto de próxima generación mantenido por Epic Games
- Fue diseñado con el objetivo de ofrecer alta escalabilidad en volumen de datos, tamaño de los equipos, distribución de los equipos y tamaño de los repositorios
- Está optimizado para proyectos que usan tanto código como grandes recursos binarios
- Se presentan como ejemplo proyectos de la industria de videojuegos y entretenimiento
- Atiende al mismo tiempo las necesidades de colaboración entre desarrolladores y artistas
- Puede iniciarse en modo local en cuestión de minutos y luego escalar según sea necesario
- Proporciona una base para que los equipos construyan flujos de trabajo de colaboración rápidos, intuitivos y prácticos
Estructura para escalabilidad y manejo de archivos grandes
-
Datos compartidos y API
- Las funciones principales están orientadas a la escalabilidad y al manejo de grandes recursos
- Busca escalar sin pérdida de velocidad mediante datos compartidos y reutilizables y descargas en el momento necesario
- Permite crear, administrar y sincronizar ramas rápidamente
- Se puede acceder a toda la funcionalidad de Lore de forma uno a uno mediante la CLI
- Soporta extensión, personalización e integración con API para C/C++, C#, Rust, Go, Python y JavaScript
-
Repositorio basado en direccionamiento por contenido
- La estructura del repositorio es un sistema de control de versiones content-addressed centralizado
- Los datos del repositorio se almacenan y referencian mediante hashes de contenido y se representan con un árbol de Merkle
- Soporta comparaciones rápidas, verificación de integridad y reutilización de datos entre historial y ramas
- La firma hash de una revisión se deriva del estado de la revisión, incluyendo el hash de la revisión padre y los hashes de los datos incluidos
- Esta estructura forma una cadena inmutable con integridad criptográfica
-
Almacenamiento por chunks y descargas en el momento necesario
- El manejo de archivos grandes y workspaces usa almacenamiento por chunks y on-demand hydration
- Los archivos se almacenan como chunks reutilizables y usan consulta basada en índices
- Reduce duplicación y mejora la eficiencia de actualización y transferencia de grandes recursos binarios
- El workspace puede mantenerse liviano al traer solo los datos de archivo necesarios
- Con sparse workspace no es necesario descargar todos los datos desde el principio
-
Servidor y modelo de ramas
- La estructura del servidor es una arquitectura basada en servicios que incluye caché
- El caché delante del durable storage ayuda a escalar el rendimiento para equipos grandes y repositorios grandes
- Las ramas funcionan como referencias mutables ligeras, por lo que el costo de crearlas y cambiar entre ellas es bajo y no hay duplicación de datos base
Repositorios públicos y documentación
- Epic Games publicó Lore como software totalmente de código abierto bajo licencia MIT
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- La documentación y el documento de diseño del sistema están disponibles en Lore docs y system design doc
2 comentarios
Comentarios en Hacker News
Para dar algo de contexto a los lectores de HN que nunca han hecho juegos: esto no es una herramienta que busque competir con Git en el desarrollo de software general, sino con Perforce en el desarrollo de videojuegos
Git funciona bien para archivos basados en texto, como código, pero es muy débil para colaborar con archivos no textuales como texturas, modelos 3D y archivos de audio. Por ejemplo, no hay una forma razonable de fusionar cambios asíncronos de dos artistas, así que puede ser necesario poner un bloqueo exclusivo sobre un asset mientras un artista lo está editando
El líder de facto en este espacio es el sistema privativo Perforce(https://www.perforce.com/products/helix-core). Según mis amigos desarrolladores de juegos, cuando Perforce funciona bien es excelente, pero también tiene suficientes fricciones como para requerir que un ingeniero de herramientas lo administre y lo arregle manualmente de vez en cuando. Git LFS también es una alternativa, pero en proyectos de equipo de más de 3 o 4 personas todos prefieren más Perforce
En P4 puedes restringir el acceso a ciertos directorios para que solo entren personas que hayan firmado el NDA necesario, pero en Git es todo o nada. Tal vez se pueda armar algo con submódulos, pero si no fue diseñado así desde el principio, terminas dándole una vuelta enorme a la estructura del repositorio
git clone, o seap4 sync, puede ser de terabytesGit es débil para manejar assets binarios, texturas, modelos, sonidos, etc., a esa escala
Si tienes un asset que se actualiza seguido al inicio del desarrollo, terminas pagando ese costo de almacenamiento durante toda la vida del repositorio. En el desarrollo de juegos esto pasa mucho. La mayoría de los assets cambian varias veces al principio y, una vez terminados, ya no se vuelven a tocar
Hoy, mientras hacía push de cambios a Github, volví a pensar en lo poco amigable que es la UI de Git
Salidas como
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasquizás le digan algo a los usuarios hardcore de Git, pero para la mayoría de la gente son puro galimatías. ¿Qué demonios es la “compresión delta”, por qué tendría que saber cuántos hilos usa, y qué significan “objetos”, objetos “local” o “pack-reused”?Viendo la documentación, parece que Lore maneja un poco mejor esta parte. Se ve algo como
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch main-v. Seguramente nadie la tocó nunca, y durante décadas simplemente aprendimos a ignorarlaLos objetos son referenciados por árboles, y un árbol no es más que un directorio. A su vez, los árboles son referenciados por commits o tags para formar un DAG, y los punteros con nombre que señalan distintos puntos de ese grafo son las referencias de ramas y tags: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Tener un montón de objetos sueltos es muy ineficiente, así que Git periódicamente los agrupa en packs. Para ahorrar espacio, dentro de esos packs comprime objetos comparándolos entre sí, y eso es la compresión delta: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
Cuando haces push o pull, el protocolo de transporte de Git enumera qué objetos tiene cada lado y solo transfiere la diferencia. Además, para ahorrar espacio, aplica compresión delta a objetos que todavía no han sido empaquetados en ambos lados: https://github.com/git/git/blob/master/Documentation/technic...
Git es un proyecto open source hecho por nerds, así que te muestra toda esta información. Puedes ignorarla sin problema. Si realmente quieres entenderla, está toda documentada en el libro de Git y en el directorio de documentación enlazados arriba
Poco a poco me va cerrando más. Desde el punto de vista de la UI, es una gran mejora respecto a Git. Eso sí, el flujo de trabajo con ramas toma algo de tiempo para acostumbrarse
Recomiendo mucho mirar directamente dentro del directorio
.git. Eso hace que la demanda de soporte de Git para gente nueva baje prácticamente a ceroEste anuncio se ve muy prometedor, especialmente para el desarrollo de juegos con Unreal. Para otros usos, no me llama tanto la atención.
Perforce definitivamente necesita un competidor. Si Perforce ha sido el jugador dominante hasta ahora, no es porque sea inusualmente simple de usar o administrar. Por ejemplo, si solo miras el trabajo con ramas, Git en realidad es mucho más simple.
En desarrollo de juegos, las razones por las que P4 suele preferirse ya salieron en otros comentarios: soporte para proyectos grandes, permisos, bloqueo de archivos, etc. Otra razón clave es que P4 tiene muy buen soporte dentro de Unreal Engine. No es perfecto, pero como es la herramienta que Epic usa internamente, es el sistema de control de versiones con mejor soporte. El plugin de Git, como Epic no lo usa internamente, está tan incompleto que resulta doloroso.
Por eso espero que Lore reciba soporte de primera categoría. Si el soporte de Unreal fuera mejor, recomendaría Git mucho más seguido. Para dar contexto, llevo casi 20 años trabajando en desarrollo de juegos y he pasado por empresas de todos los tamaños, desde 2 hasta 200 personas, además de todo tipo de motores y sistemas de control de versiones. Prefiero Git donde se puede usar, pero en Unreal solo lo recomendaría para proyectos pequeños o con gente muy metida en lo técnico. Al final, se trata de elegir la herramienta que encaje con el trabajo y con el equipo.
https://github.com/EpicGames/UnrealEngine/pull/14630
En mi estudio de juegos anterior teníamos que usar Perforce, más exactamente Helix Core Cloud, que es el estándar de facto de la industria con el que la mayoría de la gente del lado creativo ya está familiarizada. A los programadores no les gusta, pero los programadores no son quienes mandan en la industria de los videojuegos. También es la opción segura y probada para usar con Unreal Engine 5.
Aun así, se le nota la edad. Como éramos pequeños y no queríamos autoalojar nada, al principio usamos el servicio cloud de Perforce, pero la experiencia fue bastante accidentada. Para acceder al servicio había que registrar una cuenta de Azure, y para cambiar cosas como los triggers había que pedirlo al equipo de soporte. Si vienes del mundo de GitHub u otros productos SaaS, se siente como un intento de ponerle una carcasa nueva a un modelo viejo.
La ruta de Git LFS también tiene algo de soporte no oficial, pero si las cosas se complican, te toca arreglarlo por tu cuenta. Epic no ayuda mucho ahí. Sobre todo si el objetivo es tener soporte oficial completo dentro del motor, la competencia en esta área sería muy bienvenida.
Escribí un texto sobre por qué en el mundo del desarrollo de juegos no es común hacer merge de archivos, para quienes vienen del desarrollo basado en texto: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
Acabo de hacerme cargo de un equipo que usaba Git, y aunque sé que Git es el sistema de control de versiones favorito de todo el mundo, para juegos está cerca de ser una de las peores opciones posibles. Con Git, el tiempo de revisión de arte lo medíamos en horas; con Perforce, en segundos. No es broma.
Herramientas interesantes que usa UE5, como Horde o UBA, requieren Perforce.
Pero Perforce no ha hecho nada con su posición en la industria. Es carísimo y además no es que operar el hosting sea gratis. Hay que alojarlo uno mismo, y por rendimiento conviene hacerlo así, pero el mantenimiento después de la instalación inicial es realmente doloroso. Se nota que intentan cosas, pero sin una dirección clara, y casi todo lo que han hecho va en contra del sentido común o de su propia base de usuarios. El producto principal sigue cambiando de nombre, pero no mejora de verdad.
Es una lección de cómo el software propietario puede convertirse en una cárcel. Quiero usar una herramienta de revisión de código mejor que Swarm, integrar SSO sin hooks raros en LUA que me causan segfaults en mi equipo, y correr un backend de almacenamiento distribuido en lugar de depender de SSD gigantes y respaldos del journal. Incluso la licencia está atada a la IP del servidor principal, así que ni siquiera sirve para recuperación de backups.
Es una tecnología olvidada, y quienes manejan esa empresa parecen zombis.
No sé si ya resolvieron el tema de permisos, o si ya está resuelto este modelo híbrido de control de versiones distribuido/centralizado donde el checkout a nivel de archivo interactúa con el trabajo tradicional basado en ramas.
Si miras el FAQ, en realidad no es un producto completamente nuevo, sino algo que apenas ahora liberaron como open source.
“Lore, antes llamado Unreal Revision Control, es un sistema de control de versiones integrado en UEFN (Unreal Editor for Fortnite) y los creadores lo han usado para gestionar las versiones de sus islas. Los equipos internos de Epic también lo están adoptando gradualmente, y se está implementando como el repositorio backend del pipeline de cook de UEFN, reemplazando la capa intermedia de almacenamiento existente para eliminar transferencias de archivos duplicados y reducir considerablemente el tiempo entre publicar cambios y que se puedan jugar”, según explican.
Sorprende que esté hecho en Rust y no en Epic C++ ni en Verse. Da curiosidad saber por qué.
La razón para no usar Verse probablemente sea que ese trabajo no encajaba con Verse. Incluso si Simon trabaja en Verse, eso seguiría siendo cierto. Y que no sea Haskell sino Rust seguramente se deba al rendimiento. DARCS tampoco logró una adopción amplia en parte por problemas de rendimiento.
Además, eso la ataría a todos los problemas y la lentitud del motor. Epic ya cometió ese error con Epic Games Launcher. Básicamente funciona ejecutando una instancia del motor, y esa es una gran fuente de muchos problemas.
Si comparas Verse con Rust, Verse se usa dentro de la experiencia de UEFN, pero todavía está lejos de estar listo para producción. Además, está esencialmente atado a UEFN. No es como si pudieras descargar un compilador independiente o un REPL.
Claro, sería distinto si la estuvieran publicando porque decidieron dejar de desarrollarla, pero no parece ser el caso aquí.
Full-surface API es una característica que nadie aquí ha mencionado. Me pregunto si se refiere a Git y a que deliberadamente no ofrece una librería enlazable. Antes vi este post: https://news.ycombinator.com/item?id=48470604
porcelainpara interactuar con programas. No es enlazable, pero igual es una API.La premisa es que Git-LFS no da la talla, así que hay que crear desde cero en Rust un nuevo sistema de control de versiones de datos. En general coincido con esa premisa, pero ya existen bastantes sistemas maduros de control de versiones de datos que internamente usan trucos similares.
Pachyderm(Go): https://github.com/pachyderm/pachyderm
XetHub(adquirido por HuggingFace): https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go): https://github.com/treeverse/lakeFS
Oxen(Rust): https://github.com/Oxen-AI/Oxen
Supongo que gracias a la IA ahora cualquiera puede hacer vibe coding en Rust de direccionamiento por contenido, deduplicación por chunks y sistemas de control de versiones.
Bromas aparte, Lore sí se ve muy bien. Lo interesante es que distintos dominios e industrias parecen tener problemas parecidos, pero no parece haber mucho intercambio de ideas. En este caso, tanto la IA como los juegos necesitan sistemas de almacenamiento para versionado de archivos binarios grandes. Parece haber muchas oportunidades para compartir ideas, y la falta actual de ese intercambio incluso podría ser una oportunidad.
Solo esa diferencia ya podría requerir arquitecturas de almacenamiento distintas.
Creo que parte del problema eran los compromisos necesarios para mantener Git y un almacenamiento híbrido. Por eso me alegra que este sistema de control de versiones no use Git. xethub también empezó a sacar una versión del producto que no usa Git, aunque no tuve oportunidad de probarla.
También probé oxen y al principio no estaba mal, pero pronto me topé con problemas raros relacionados con el estado del repositorio y no me puse a depurarlos a fondo. Después de pasar por todos estos sistemas, quedó claro que ninguno resulta 100% satisfactorio y que Git para datos no es un problema menor.
Me pregunto qué empresa realmente desplegará este sistema, por ejemplo, en los próximos 2 años.
Helix y Perforce llevan décadas haciendo esto y se puede confiar en ellos porque es parte de su negocio principal. Sabes que van a seguir manteniendo el producto durante un buen tiempo.
Pero si Epic abandona este proyecto mañana, no le pasa nada a su negocio. Incluso podría beneficiarle al recuperar recursos de desarrollo para otras cosas del negocio.
Es parecido a preguntarse por qué alguien confiaría en que Cloudflare seguirá invirtiendo a largo plazo en EmDash. Cloudflare no tiene interés en los CMS. No es su negocio ofrecer la mejor experiencia a lectores, autores y dueños de sitios. Es casi un proyecto secundario, muy alejado de su actividad principal.
En este espacio siempre ha existido un competidor bastante decente llamado PlasticSCM. Unity lo adquirió hace algunos años, pero Unity no fue un buen administrador.
Deberían haberlo liberado como open source, como está haciendo Epic, pero en cambio optaron por cargarle responsabilidad de pérdidas y ganancias. Me pregunto cuánto estará aportando a las finanzas de Unity.
Opiniones en Lobste.rs
Si está optimizado para proyectos de juegos/entretenimiento que manejan código y grandes recursos binarios al mismo tiempo, al fin parece que alguien se cansó del monopolio de décadas de Perforce e hizo algo al respecto
Cuando lo vi por primera vez, creo que no estaba, pero me pregunto por qué ahora tiene la etiqueta de vibecoding
Por ejemplo, una explicación del tipo “Mercurial y Sapling se centran en el historial de texto y Lore prioriza binarios” es incorrecta. Mercurial también tiene una estructura donde las funciones de texto están montadas sobre un modelo de objetos binarios
Como alguien que participó en el desarrollo de Mercurial/Sapling, creo que un LLM puede aumentar el rigor al señalar alternativas que el equipo pasó por alto, pero este documento me decepcionó. La decisión en sí tiene muchas ventajas, pero ojalá hubiera sido un documento escrito con mucho más rigor
2026-06-17 12:56 (Users)
Story: Epic Games announces Lore version control system
Action: changed tags from "release vcs" to "release vcs vibecoding"
Reason: Automatically changed from user suggestions
¿Será este el primer proyecto en Rust que Epic Games hace público?
Viendo esto y las noticias del más reciente sistema de control de versiones de Cursor, parece que estos días todo el mundo quiere hacer un VCS
¿Fui el único cuya primera reacción fue “esto no debería estar hosteado sobre lore”?