Epic Games hat mit Lore ein eigenes Versionskontrollsystem als Open-Source-Projekt veröffentlicht. Die Software richtet sich vor allem an Entwicklungsumgebungen, in denen große Binärdateien, umfangreiche Asset-Bestände und verteilte Teams zum Alltag gehören. Damit adressiert Lore ein Feld, in dem klassische Git-Workflows, Git LFS und etablierte Systeme wie Perforce seit Jahren unterschiedliche Kompromisse eingehen.
Lore ist als zentrales Versionskontrollsystem mit Offline-Funktionen konzipiert. Der Server bleibt die maßgebliche Quelle für Berechtigungen, Haltbarkeit und Konfliktauflösung, während lokale Clients weiterhin Änderungen vorbereiten, commiten, zwischen Branches wechseln und Teile des Repositorys bearbeiten können, ohne dauerhaft mit dem Server verbunden zu sein. Diese Kombination zielt auf Produktionsumgebungen, in denen ein vollständiger Klon großer Repositories weder notwendig noch praktikabel ist.
Binärdateien stehen im Mittelpunkt
Ein zentraler Unterschied zu Git liegt im Umgang mit großen Binärdaten. Git wurde ursprünglich für Quellcode und textbasierte Änderungen entwickelt. Große Dateien werden in vielen Projekten über Git LFS ausgelagert. Lore behandelt Dateien dagegen grundsätzlich als Byte-Ströme und setzt textorientierte Funktionen wie Diffs oder Merge-Ansichten darauf auf. Binärdaten sind damit kein Sonderfall, sondern Teil des grundlegenden Designs.
Für große Dateien nutzt Lore eine Fragmentierung in kleinere Bestandteile. Änderungen an einer mehrgigabytegroßen Datei sollen dadurch nicht zwangsläufig dazu führen, dass die komplette Datei erneut übertragen werden muss. Stattdessen werden nur geänderte Fragmente neu gespeichert oder übertragen. Die Deduplikation erfolgt auf Basis inhaltsadressierter Daten und nutzt BLAKE3 als Hash-Funktion. So lassen sich identische Inhalte wiederverwenden, auch wenn sie in unterschiedlichen Dateien oder Versionen vorkommen.
Relevant ist dieser Ansatz vor allem für Game-Studios, die mit Texturen, Modellen, Audiodaten, Build-Artefakten und Editor-Dateien arbeiten. Solche Daten lassen sich häufig nicht sinnvoll zeilenweise vergleichen oder automatisch zusammenführen. Lore berücksichtigt das unter anderem durch File-Locking für Inhalte, die sich nicht sinnvoll mergen lassen.
Wie sich Lore zu Git, Git LFS und Perforce verhält
Der Vergleich mit Perforce ist im Games-Bereich naheliegend. Perforce Helix Core gilt seit Jahren als verbreitete Lösung für große Spielproduktionen, gerade wegen zentraler Serverstrukturen, Dateisperren und besserer Eignung für große Binärdateien. Auch Epic verweist in seiner Unreal-Dokumentation darauf, intern Perforce zu nutzen. Lore übernimmt einige dieser Grundannahmen, etwa den zentralen Server als maßgebliche Instanz und das Locking für nicht mergebare Dateien, setzt darunter aber auf ein anderes Speichermodell.
Während Perforce traditionell stark serverzentriert arbeitet und viele Operationen eine Verbindung zum Server voraussetzen, soll Lore lokale Arbeitsabläufe stärker ermöglichen. Entwickler können Änderungen lokal vorbereiten und erst später mit dem zentralen System synchronisieren. Gegenüber Git wiederum will Lore dort ansetzen, wo Git bei großen Binärdateien, partiellen Arbeitskopien und Multi-Tenant-Serverstrukturen zusätzliche Werkzeuge oder Infrastruktur benötigt.
Damit ist Lore nicht einfach ein Ersatz für Git in klassischen Code-Repositories. Der Ansatz wirkt eher wie eine Antwort auf Produktionsrealitäten in großen Studios: Ein Repository enthält nicht nur Quellcode, sondern auch Assets, generierte Daten, Build-Zwischenstände und Dateien, die sich nicht wie Text behandeln lassen. Für kleine Teams oder klassische Softwareprojekte bleibt Git weiterhin ausreichend. Für große Content-Pipelines könnte Lore dagegen eine Alternative oder Ergänzung zu bestehenden Perforce-Setups werden, sofern sich das System in der Praxis bewährt.
Noch frühes Projekt mit offener Spezifikation
Lore ist in Rust geschrieben und wird unter der MIT-Lizenz veröffentlicht. Die Architektur trennt Versionsverwaltung und Speichersystem voneinander. Das Speichersystem lässt sich dadurch auch unabhängig von der eigentlichen Versionskontrolle nutzen, etwa für deduplizierte Auslieferung großer Binärdaten oder als Backend für Build- und Asset-Pipelines.
Die Kommunikation mit dem Server erfolgt über eine API. Das Kommandozeilenwerkzeug setzt im Wesentlichen auf diese Schnittstellen auf. Bindings existieren unter anderem für C#, Go, JavaScript und Python. Laut Dokumentation sind die Formate und Protokolle öffentlich beschrieben, gleichzeitig befindet sich Lore noch in Entwicklung. Schnittstellen, Speicherformate und einzelne Funktionen können sich daher noch ändern.
Für professionelle Teams dürfte entscheidend sein, wie gut sich Lore in bestehende Toolchains integrieren lässt. Gerade Unreal-Produktionen verfügen häufig über etablierte Perforce-Strukturen, CI-Systeme, Asset-Workflows und Rechtekonzepte. Lore bringt dafür mehrere interessante Bausteine mit, darunter Sparse Working Copies, API-zentriertes Design, fragmentbasierte Speicherung, Multi-Tenant-Isolation und austauschbare Storage-Backends. Ob daraus eine praxistaugliche Alternative für große Produktionen wird, hängt weniger von der technischen Idee als von Stabilität, Tooling und Integration in bestehende Pipelines ab.