Lore – Sistema de control de versiones de código abierto diseñado para la escalabilidad

Artículo original ↗ Discusión en Hacker News ↗

Epic Games ha publicado como código abierto Lore, un sistema centralizado de control de versiones diseñado para manejar proyectos de videojuegos masivos con grandes activos binarios, con el objetivo de cubrir las carencias donde Git y Git LFS tienen dificultades y competir con Perforce. Los comentaristas destacan características como almacenamiento segmentado, bloqueo de archivos, sparse checkouts e integración profunda con el motor como potencialmente transformadoras para los flujos de trabajo de juegos y medios, especialmente para los artistas. El entusiasmo se ve atenuado por dudas sobre la preparación para producción de Lore, su dependencia de Epic, su arquitectura centralizada y señales de documentación generada por LLM, además de preguntas sobre si realmente mejora en la práctica respecto a las herramientas existentes.

Uso previsto y posicionamiento

  • Se lo ve principalmente como un sustituto de Perforce para el desarrollo de videojuegos y otros flujos de trabajo con muchos activos, no como un reemplazo general de Git.
  • Usuarios objetivo: equipos que mezclan programadores y artistas, con repositorios medidos en cientos de GB–TB y dominados por activos binarios (texturas, modelos, audio, niveles).

Por qué Git (y Git LFS) tienen dificultades aquí

  • Git es excelente para texto/código, pero malo para binarios grandes:
    • Los repositorios y clones crecen rápidamente; el historial se vuelve enorme y lento.
    • Git LFS añade bloqueo e indirección, pero se describe como frágil, confuso y difícil de configurar a escala; se mencionan frecuentes problemas de autenticación y corrupción.
    • No hay permisos de grano fino; el acceso es para todo el repositorio, salvo que dividas repos o uses submódulos incómodos.
    • Sparse checkout y partial clones existen, pero son delicados y poco amigables para artistas.
  • La CLI y la salida de Git son criticadas ampliamente por ser confusas y demasiado verbosas, especialmente para no ingenieros.

Cómo afirma ayudar Lore

  • Diseñado en torno a grandes activos binarios:
    • Almacenamiento segmentado para deduplicación y transferencias parciales más rápidas.
    • Hidratación bajo demanda / copias de trabajo dispersas para que los usuarios solo descarguen los activos que necesitan.
    • Bloqueo nativo de archivos para evitar ediciones concurrentes de activos que no se pueden fusionar.
    • Permisos por directorio/activo y aislamiento multiusuario.
  • CLI al estilo Git para desarrolladores; se promete un cliente de escritorio con GUI para artistas (el binario está disponible ahora, el código fuente se abrirá más adelante).
  • Se pretende una superficie API completa, a diferencia de la postura de Git de “sin biblioteca”.

Centralización, escala y arquitectura

  • Lore es explícitamente centralizado (más parecido a Perforce que a Git); el peer-to-peer no es un objetivo.
  • Está diseñado para soportar cosas como canalizaciones de Unreal Engine/UEFN; se describe como ya usado internamente para contenido de Fortnite.
  • Los despliegues multi-región dependen actualmente de servicios de AWS como DynamoDB, lo que genera preocupaciones sobre la dependencia de la nube.

Herramientas, UX y preocupaciones sobre adopción

  • Muchos subrayan que UE y Perforce funcionan bien juntos hoy; la inercia de migración es alta porque a los artistas no les gusta aprender herramientas nuevas.
  • Se considera que el éxito de Lore depende de una integración profunda con Unreal, Unity, herramientas DCC (Maya, Blender, etc.) y una GUI pulida.
  • Algunos preguntan si Lore es lo bastante bueno con texto/código como para reemplazar Git en toda la organización; otros señalan el bloqueo del ecosistema alrededor de las herramientas de Git.

Confianza en Epic y madurez del proyecto

  • Escepticismo sobre atar infraestructura crítica a Epic:
    • Se citan decisiones pasadas (p. ej., abandonar soporte para Linux/macOS en juegos, controversias de Epic Store) como problemas de confianza.
    • Hay temor de que Lore pueda ser abandonado o convertido en una oferta “open core” a pesar de la licencia MIT.
  • La documentación y las páginas de diseño se perciben ampliamente como generadas por LLM, verbosas y difíciles de leer; esto socava la confianza en el rigor aunque el sistema subyacente pueda ser sólido.
  • Algunos señalan que todavía no está “listo para producción” según su propia FAQ; muchos esperarán más informes del mundo real.

Aplicabilidad más amplia y comparaciones

  • Otros dominios (datasets de ML/IA, CAD, modelado 3D, fotografía, PDM/PLM) ven potencial en un VCS orientado primero a binarios.
  • Comparado con herramientas existentes de datos/BLOB (git-annex, DVC, lakeFS, Pachyderm, Oxen, XetHub) y otros VCS (Mercurial, SVN, PlasticSCM, Diversion, jj, Pijul); el consenso es que “Git para datos/gamedev” sigue siendo un problema difícil sin resolver, así que más experimentación es bienvenida.