- Lore, gepflegt von Epic Games, ist ein Open-Source-Versionsverwaltungssystem der nächsten Generation für Projekte, die Code und große binäre Assets gemeinsam verwalten
- Es lässt sich lokal schnell starten und bei Bedarf erweitern und unterstützt große Repositories und Teams durch geteilte, wiederverwendbare Daten sowie Downloads zum benötigten Zeitpunkt
- Es verwendet ein zentralisiertes content-addressed Repository und stellt den Repository-Zustand sowie die Änderungshistorie mit einem Merkle Tree und einer unveränderlichen Revision Chain dar
- Große Dateien werden in wiederverwendbaren Chunks gespeichert, und dank Sparse Workspaces und On-Demand Hydration müssen nicht von Anfang an alle Daten heruntergeladen werden
- Es wurde unter der MIT-Lizenz veröffentlicht und bietet CLI-, C/C++-, C#-, Rust-, Go-, Python- und JavaScript-APIs sowie mehrere SDK-Repositories
Versionsverwaltung für Code und große Assets gemeinsam
- Lore ist ein Open-Source-Versionsverwaltungssystem der nächsten Generation, das von Epic Games gepflegt wird
- Es wurde mit dem Ziel hoher Skalierbarkeit bei Datenumfang, Teamgröße, Teamverteilung und Repository-Größe entwickelt
- Es ist für Projekte optimiert, die Code und große binäre Assets gemeinsam nutzen
- Als Beispiel werden Projekte aus der Spiele- und Unterhaltungsindustrie genannt
- Es adressiert zugleich die Anforderungen an die Zusammenarbeit von Entwicklern und Artists
- Im lokalen Modus kann man in wenigen Minuten starten und anschließend nach Bedarf skalieren
- Es bietet die Grundlage, auf der Teams schnelle, intuitive und praktische kollaborative Workflows aufbauen können
Architektur für Skalierbarkeit und den Umgang mit großen Dateien
-
Geteilte Daten und APIs
- Die Kernfunktionen sind auf Skalierbarkeit und den Umgang mit großen Assets ausgelegt
- Ziel ist eine Skalierung ohne Geschwindigkeitseinbußen durch geteilte, wiederverwendbare Daten und Downloads zum benötigten Zeitpunkt
- Branches lassen sich schnell erstellen, verwalten und synchronisieren
- Über die CLI ist ein Eins-zu-eins-Zugriff auf alle Funktionen von Lore möglich
- APIs für C/C++, C#, Rust, Go, Python und JavaScript unterstützen Erweiterung, Anpassung und Integration
-
Content-addressed Repository
- Die Repository-Struktur ist ein zentralisiertes content-addressed Versionsverwaltungssystem
- Repository-Daten werden über Content-Hashes gespeichert und referenziert und als Merkle Tree dargestellt
- Dies unterstützt schnelle Vergleiche, Integritätsprüfungen sowie die Wiederverwendung von Daten zwischen Historie und Branches
- Die Hash-Signatur einer Revision wird aus dem Revisionszustand abgeleitet, einschließlich des Hashes der Parent-Revision und der enthaltenen Daten-Hashes
- Diese Struktur bildet eine unveränderliche Kette mit kryptografischer Integrität
-
Chunk-Speicherung und Downloads bei Bedarf
- Für große Dateien und Workspaces werden Chunk-Speicherung und On-Demand Hydration verwendet
- Dateien werden in wiederverwendbaren Chunks gespeichert und per indexbasierter Abfrage abgerufen
- Das reduziert Duplikate und macht Updates und Übertragung großer binärer Assets effizienter
- Ein Workspace kann schlank bleiben, indem nur die benötigten Dateidaten geladen werden
- Mit Sparse Workspaces müssen nicht von Anfang an alle Daten heruntergeladen werden
-
Server- und Branch-Modell
- Die Serverstruktur ist eine servicebasierte Architektur mit Caching
- Caching vor dem Durable Storage unterstützt die Skalierung des Durchsatzes für große Teams und große Repositories
- Branches fungieren als leichtgewichtige mutable References, sodass Erstellung und Wechsel wenig kosten und keine grundlegende Datenduplizierung entsteht
Öffentliche Repositories und Dokumentation
- Epic Games hat Lore vollständig als Open Source unter der MIT-Lizenz veröffentlicht
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- Dokumentation und Systemdesign-Dokumente sind in den Lore docs und im system design doc verfügbar
2 Kommentare
Hacker-News-Kommentare
Als Kontext für HN-Leser, die nie Spiele entwickelt haben: Das hier ist kein Tool, das im allgemeinen Software-Development mit Git konkurrieren will, sondern im Game Development mit Perforce
Git ist okay für textbasierte Dateien wie Code, aber sehr schwach bei der Zusammenarbeit an Nicht-Text-Dateien wie Texturen, 3D-Modellen oder Audiodateien. Es gibt zum Beispiel keine vernünftige Möglichkeit, asynchrone Änderungen von zwei Artists zusammenzuführen, daher muss man unter Umständen eine exklusive Sperre auf ein Asset setzen, während ein Artist daran arbeitet
Der De-facto-Marktführer in diesem Bereich ist das proprietäre System Perforce(https://www.perforce.com/products/helix-core). Laut meinen Freunden aus der Spieleentwicklung ist Perforce großartig, wenn es gut läuft, hat aber auch genug Reibungspunkte, dass Tool Engineers es verwalten und gelegentlich manuell reparieren müssen. Git LFS ist ebenfalls eine Alternative, aber bei Teamprojekten mit mehr als 3 bis 4 Personen bevorzugen offenbar alle Perforce
In P4 kann man den Zugriff auf bestimmte Verzeichnisse auf Personen beschränken, die die nötige NDA unterschrieben haben, während es bei Git eher alles oder nichts ist. Mit Submodulen könnte man sich etwas zusammenbauen, aber wenn das nicht von Anfang an so geplant war, muss man dafür die Repository-Struktur massiv umwerfen
git clone, alsop4 sync, in der Spieleentwicklung Terabytes umfassen kannGit ist schwach darin, binäre Assets, Texturen, Modelle, Sounds usw. in diesem Umfang zu handhaben
Wenn es in einer frühen Entwicklungsphase Assets gibt, die häufig aktualisiert werden, zahlt man für diesen Speicherplatz über die gesamte Lebensdauer des Repositories. Im Game Development passiert das häufig. Die meisten Assets gehen anfangs viele Male hin und her und werden nach der Fertigstellung nie wieder angefasst
Während ich heute Änderungen auf GitHub gepusht habe, musste ich wieder daran denken, wie wenig benutzerfreundlich die Git-UI ist
Ausgaben wie
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasmögen Hardcore-Git-Nutzern etwas sagen, aber für die meisten Menschen sind sie komplettes Kauderwelsch. Was genau ist bitte „Delta compression“, warum sollte ich wissen müssen, wie viele Threads verwendet werden, und was bedeuten „objects“, „local objects“ oder „pack-reused“ überhaupt?Laut Dokumentation scheint Lore diesen Teil etwas besser zu machen. Es sieht eher so aus wie
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch main-vstehen sollten. Vermutlich hat es nur nie jemand angefasst, und wir haben über Jahrzehnte einfach gelernt, es zu ignorierenObjekte werden von Trees referenziert, und Trees sind einfach Verzeichnisse. Diese Trees werden wiederum von Commits oder Tags referenziert und bilden so einen DAG, während Branches und Tag-Refs benannte Pointer auf verschiedene Punkte darin sind: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Viele lose Objekte herumliegen zu lassen ist sehr ineffizient, deshalb bündelt Git Objekte regelmäßig in Packs. Um Platz zu sparen, werden Objekte innerhalb eines Packs gegeneinander verglichen und komprimiert; das ist Delta-Komprimierung: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
Beim Push oder Pull listet das Git-Transportprotokoll auf, welche Objekte beide Seiten bereits besitzen, und überträgt nur die Unterschiede. Zusätzlich werden noch nicht gepackte Objekte auf beiden Seiten delta-komprimiert, um Platz zu sparen: https://github.com/git/git/blob/master/Documentation/technic...
Git ist ein Open-Source-Projekt, das von Nerds gebaut wurde, deshalb zeigt es all diese Informationen an. Man kann sie einfach ignorieren. Wenn man es wirklich wissen will, ist alles im oben verlinkten Git-Buch und im Dokumentationsverzeichnis beschrieben
Inzwischen leuchtet es mir immer mehr ein. Aus UI-Sicht ist es eine große Verbesserung gegenüber Git. Allerdings braucht der Branching-Workflow etwas Eingewöhnung
Ich empfehle dringend, sich das
.git-Verzeichnis direkt anzusehen. Dann sinkt der Bedarf an Git-Support für neue Mitarbeiter praktisch auf nullDiese Ankündigung ist besonders für die Unreal-Spieleentwicklung sehr vielversprechend. Für andere Einsatzzwecke interessiert sie mich nicht besonders.
Perforce braucht definitiv einen Konkurrenten. Dass Perforce der etablierte Platzhirsch ist, liegt nicht daran, dass Nutzung oder Administration außergewöhnlich einfach wären. Wenn man sich zum Beispiel nur die Arbeit mit Branches ansieht, ist Git in der Praxis deutlich einfacher.
Dass P4 in der Spieleentwicklung oft bevorzugt wird, liegt an den Punkten, die auch in anderen Kommentaren schon genannt wurden: Unterstützung für große Projekte, Berechtigungen, Dateisperren usw. Ein weiterer zentraler Grund ist, dass P4 in Unreal Engine sehr gut unterstützt wird. Es ist nicht perfekt, aber weil Epic intern damit arbeitet, ist es das am besten unterstützte Versionsverwaltungssystem. Das Git-Plugin nutzt Epic intern nicht, deshalb ist es schmerzhaft unfertig.
Deshalb erwarte ich, dass Lore erstklassigen Support bekommen wird. Wenn die Unterstützung in Unreal besser wäre, würde ich Git sehr viel häufiger empfehlen. Zur Einordnung: Ich arbeite seit fast 20 Jahren in der Spieleentwicklung und habe Firmen von 2 bis 200 Personen sowie alle möglichen Engines und Versionsverwaltungssysteme erlebt. Wo es sinnvoll einsetzbar ist, bevorzuge ich Git, aber bei Unreal nur bei kleinen Projekten oder wenn die Teammitglieder technisch versiert sind. Man sollte einfach das Werkzeug wählen, das zur Arbeit und zum Team passt.
https://github.com/EpicGames/UnrealEngine/pull/14630
In meinem vorherigen Spielestudio mussten wir Perforce verwenden, genauer gesagt Helix Core Cloud; für die meisten Kreativrollen ist das bereits der vertraute De-facto-Industriestandard. Programmierer mögen es nicht, aber in der Spieleindustrie haben nicht die Programmierer das Sagen. Zusammen mit Unreal Engine 5 ist es die sichere, bewährte Standardwahl.
Man merkt aber sein Alter. Wir waren klein und wollten kein Self-Hosting, deshalb haben wir früh den Perforce-Cloud-Service genutzt, und die Erfahrung war ziemlich holprig. Um auf den Service zugreifen zu können, musste man ein Azure-Konto registrieren, und wenn man Dinge wie Trigger ändern wollte, musste man den Support kontaktieren. Wenn man aus der Welt von GitHub oder anderen SaaS-Produkten kommt, fühlt es sich an wie der Versuch, einem alten Modell nur eine neue Hülle zu geben.
Der Weg mit Git LFS wird inoffiziell ein wenig unterstützt, aber wenn etwas schiefläuft, muss man es selbst ausbaden. Epic hilft dort nicht viel. Gerade wenn man in der Engine auf vollständigen offiziellen Support abzielt, ist Konkurrenz in diesem Bereich sehr zu begrüßen.
Für Leute aus der textbasierten Entwicklung habe ich aufgeschrieben, warum Dateimerge in der Spieleentwicklung nicht üblich ist: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
Ich habe gerade ein Team übernommen, das Git verwendet hat, und obwohl Git das Versionsverwaltungssystem ist, das alle lieben, ist es für Spiele fast die schlechtestmögliche Wahl. Mit Git musste man die Zeit für Art-Reviews in Stunden messen, mit Perforce in Sekunden. Kein Witz.
Einige der interessanten Werkzeuge, die UE5 verwendet, etwa Horde oder UBA, setzen Perforce voraus.
Perforce hat seine Branchenstellung jedoch genutzt, ohne irgendetwas zu tun. Es ist extrem teuer, und das Hosting verursacht ebenfalls Kosten. Man muss es selbst hosten, und aus Performancegründen ist das auch besser, aber die Wartung nach der Erstinstallation ist wirklich qualvoll. Es gibt Anzeichen, dass man irgendetwas versucht, aber keine klare Richtung, und fast alles, was getan wurde, widerspricht dem gesunden Menschenverstand oder der eigenen Nutzerschaft. Das Kernprodukt bekommt ständig nur neue Namen, ohne echte Verbesserungen.
Es ist eine Lehrstunde darin, wie proprietäre Software zum Gefängnis wird. Ich möchte ein besseres Code-Review-Werkzeug als Swarm verwenden, SSO integrieren ohne seltsame LUA-Hooks, die auf meiner Maschine Segfaults auslösen, und ein verteiltes Storage-Backend betreiben, statt auf riesige SSDs und Journal-Backups angewiesen zu sein. Sogar die Lizenz ist an die IP-Adresse des Hauptservers gebunden, sodass nicht einmal Backup-Wiederherstellung möglich ist.
Es ist vergessene Technologie, und die Organisation, die diese Firma betreibt, wirkt wie ein Zombie.
Ich weiß nicht, ob die Berechtigungsprobleme geklärt sind oder ob dieses hybride verteilte/zentralisierte Versionsverwaltungsmodell mit Checkout auf Dateiebene und seiner Wechselwirkung mit traditioneller branchbasierter Arbeit gelöst ist.
Im FAQ steht, dass es sich in Wirklichkeit nicht um ein völlig neues Produkt handelt, sondern dass es erst jetzt als Open Source veröffentlicht wurde.
„Lore, früher Unreal Revision Control genannt, ist ein in UEFN (Unreal Editor for Fortnite) integriertes Versionskontrollsystem, das Creator bislang zur Verwaltung der Versionen ihrer Inseln genutzt haben. Auch interne Teams bei Epic führen es schrittweise ein, und es wird als Backend-Repository der Cook-Pipeline von UEFN implementiert, um die bestehende Zwischenspeicher-Schicht zu ersetzen, doppelte Dateiübertragungen zu vermeiden und die Zeit vom Veröffentlichen einer Änderung bis zur Spielbarkeit deutlich zu verkürzen“, heißt es dort.
Überraschend ist, dass es nicht in Epic C++ oder Verse, sondern in Rust geschrieben ist. Ich frage mich, warum.
Dass es nicht Verse wurde, liegt wahrscheinlich daran, dass sich diese Aufgabe nicht für Verse eignete. Das würde selbst dann gelten, wenn Simon an Verse arbeitet. Dass es nicht Haskell wurde, dürfte wahrscheinlich an der Performance liegen. Auch DARCS konnte sich wegen Performance-Problemen nie wirklich breit durchsetzen.
Außerdem würde man sich damit an die ganzen Probleme und die Langsamkeit der Engine ketten. Epic hat diesen Fehler schon beim Epic Games Launcher gemacht. Der läuft faktisch als eine gestartete Engine-Instanz und ist dadurch eine große Quelle vieler Probleme.
Vergleicht man Verse mit Rust, dann wird Verse zwar innerhalb der UEFN-Erfahrung verwendet, ist aber noch weit von einem produktionsreifen Zustand entfernt. Außerdem ist es seinem Wesen nach an UEFN gebunden. Man kann auch keinen eigenständigen Compiler oder REPL dafür herunterladen.
Natürlich wäre das anders, wenn es als Open Source freigegeben würde, weil die Entwicklung eingestellt werden soll, aber das scheint hier nicht der Fall zu sein.
Die Full-surface API ist eine Funktion, die hier sonst niemand erwähnt hat. Ich frage mich, ob das auf Git zielt, das absichtlich keine linkbare Bibliothek bereitstellt. Diesen Beitrag hatte ich dazu schon einmal gesehen: https://news.ycombinator.com/item?id=48470604
porcelainfür die Interaktion mit Programmen. Das ist zwar nicht in linkbarer Form, aber trotzdem eine API.Die Grundannahme ist, dass Git-LFS nicht gut genug ist und man deshalb ein neues Daten-Versionsverwaltungssystem von Grund auf in Rust bauen muss. Dieser Annahme stimme ich im Großen und Ganzen zu, aber es gibt intern bereits einige ausgereifte bestehende Daten-Versionsverwaltungssysteme, die ähnliche Tricks verwenden.
Pachyderm (Go): https://github.com/pachyderm/pachyderm
XetHub (von HuggingFace übernommen): https://huggingface.co/blog/xethub-joins-hf
LakeFS (Go): https://github.com/treeverse/lakeFS
Oxen (Rust): https://github.com/Oxen-AI/Oxen
Dank AI leben wir heute offenbar in einer Zeit, in der jeder in Rust per Vibecoding ein inhaltsadressiertes, Chunk-basierendes Deduplizierungs- und Versionsverwaltungssystem bauen kann.
Scherz beiseite: Lore sieht wirklich großartig aus. Interessant ist, dass verschiedene Domänen und Branchen offenbar ähnliche Probleme haben, es aber nicht viel Austausch von Ideen zu geben scheint. In diesem Fall brauchen sowohl AI als auch Games große Speichersysteme für die Versionsverwaltung großer Binärdateien. Es scheint viele Gelegenheiten zum Austausch von Ideen zu geben, und gerade der bisher mangelnde Austausch könnte selbst schon eine Chance sein.
Dieser Unterschied allein könnte schon unterschiedliche Repository-Architekturen erforderlich machen.
Ein Teil des Problems war meiner Meinung nach Git selbst und die Kompromisse, die nötig waren, um ein hybrides Repository beizubehalten. Deshalb freut es mich, dass dieses Versionsverwaltungssystem kein Git verwendet. xethub hat inzwischen auch begonnen, eine Produktversion ohne Git anzubieten, aber ich hatte noch keine Gelegenheit, sie auszuprobieren.
Ich habe auch oxen benutzt, und anfangs war es nicht schlecht, aber bald stieß ich auf merkwürdige Probleme mit dem Repository-Zustand und habe es nicht tiefergehend debuggt. Nachdem ich all diese Systeme erlebt habe, ist klar geworden, dass keines davon zu 100 % zufriedenstellend war und dass Git für Daten kein triviales Problem ist.
Ich frage mich, welches Unternehmen dieses System tatsächlich zum Beispiel innerhalb von 2 Jahren ausrollen wird.
Helix und Perforce machen das seit Jahrzehnten und sind vertrauenswürdig, weil es Teil ihres Kerngeschäfts ist. Man kann davon ausgehen, dass sie ihre Produkte noch eine ganze Weile warten werden.
Aber wenn Epic dieses Projekt morgen aufgeben würde, hätte das für das Geschäft keinerlei Folgen. Im Gegenteil: Es könnte dem Geschäft sogar helfen, weil dadurch Entwicklungsressourcen frei würden.
Das ist ähnlich wie die Frage, warum man glauben sollte, dass Cloudflare langfristig weiter in EmDash investieren wird. Cloudflare interessiert sich nicht für CMS. Ihr Geschäft besteht nicht darin, Leserinnen und Lesern, Autorinnen und Autoren oder Website-Betreibern die bestmögliche Erfahrung zu bieten. Es ist eher ein Nebenschauplatz, der fast nichts mit dem eigentlichen Kerngeschäft zu tun hat.
In diesem Bereich gab es schon lange bis heute mit PlasticSCM einen ziemlich guten Wettbewerber. Unity hat das Unternehmen vor ein paar Jahren übernommen, aber Unity war kein guter Verwalter davon.
Sie hätten es, wie Epic es jetzt macht, als Open Source freigeben sollen, stattdessen haben sie sich dafür entschieden, es mit Ergebnisverantwortung zu belasten. Ich frage mich, wie viel es zu den Finanzen von Unity beiträgt.
Lobste.rs-Kommentare
Wenn es für Spiele-/Entertainment-Projekte optimiert ist, die Code und große binäre Assets gemeinsam verwalten, hat offenbar endlich jemand genug von Perforces jahrzehntelangem Monopol gehabt und etwas dagegen gebaut.
Als ich es zuerst gesehen habe, war das wohl noch nicht so, aber ich frage mich, warum es jetzt mit dem Tag vibecoding versehen wurde.
Zum Beispiel ist eine Erklärung wie „Mercurial und Sapling sind textverlaufszentriert, Lore ist binärorientiert“ falsch. Auch Mercurial hat ein Binärobjektmodell, auf das Textfunktionen aufgesetzt sind.
Als jemand, der an der Entwicklung von Mercurial/Sapling beteiligt war, glaube ich, dass LLMs die Strenge erhöhen können, indem sie auf Alternativen hinweisen, die das Team übersehen hat, aber dieses Dokument war enttäuschend. Die Entscheidungen selbst haben viele Stärken, aber ich hätte mir ein deutlich strenger geschriebenes Dokument gewünscht.
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
Ist das vielleicht das erste Rust-Projekt, das Epic Games öffentlich erstellt hat?
Wenn man das hier zusammen mit den Neuigkeiten zu Cursors aktuellem Versionskontrollsystem sieht, wirkt es, als wollten momentan alle ein VCS bauen.
Bin ich der Einzige, dessen erster Gedanke war: „Sollte das nicht auf Lore gehostet werden?“