- Lore, maintenu par Epic Games, est un système open source de gestion de versions de nouvelle génération, destiné aux projets qui manipulent à la fois du code et de gros actifs binaires
- Il peut démarrer rapidement en local puis monter en charge selon les besoins, et prend en charge de grands dépôts et de grandes équipes grâce aux données partagées et réutilisables ainsi qu’au téléchargement au moment nécessaire
- Il utilise un stockage centralisé adressé par le contenu et représente l’état du dépôt ainsi que l’historique des modifications avec un arbre de Merkle et une chaîne immuable de révisions
- Les gros fichiers sont stockés sous forme de chunks réutilisables, et grâce à un workspace sparse et à l’hydratation à la demande, il n’est pas nécessaire de tout télécharger dès le départ
- Le projet est publié sous licence MIT et propose une CLI, des API C/C++, C#, Rust, Go, Python et JavaScript, ainsi que plusieurs dépôts SDK
Gestion de versions pour le code et les gros actifs
- Lore est un système open source de gestion de versions de nouvelle génération maintenu par Epic Games
- Il a été conçu avec pour objectif une forte scalabilité en matière de volume de données, de taille d’équipe, de dispersion des équipes et de taille des dépôts
- Il est optimisé pour les projets qui utilisent à la fois du code et de gros actifs binaires
- Les projets de l’industrie du jeu vidéo et du divertissement sont cités comme exemples
- Il répond à la fois aux besoins de collaboration des développeurs et des artistes
- Il peut être mis en route en quelques minutes en mode local, puis être étendu selon les besoins
- Il fournit une base permettant aux équipes de mettre en place des workflows de collaboration rapides, intuitifs et pratiques
Architecture pour la scalabilité et le traitement des gros fichiers
-
Données partagées et API
- Les fonctionnalités principales sont conçues autour de la scalabilité et de la gestion de gros actifs
- L’objectif est de monter en charge sans perte de performance grâce aux données partagées et réutilisables, ainsi qu’au téléchargement au moment nécessaire
- Il permet de créer, gérer et synchroniser rapidement des branches
- L’ensemble des fonctionnalités de Lore est accessible en correspondance directe via la CLI
- Des API pour C/C++, C#, Rust, Go, Python et JavaScript permettent l’extension, la personnalisation et l’intégration
-
Stockage adressé par le contenu
- La structure du dépôt repose sur un système de gestion de versions centralisé content-addressed
- Les données du dépôt sont stockées et référencées à l’aide de hash de contenu, et représentées par un arbre de Merkle
- Cela permet des comparaisons rapides, des vérifications d’intégrité, ainsi que la réutilisation des données entre historique et branches
- La signature de hash d’une révision est dérivée de l’état de la révision, incluant le hash de la révision parente et les hash des données qu’elle contient
- Cette structure forme une chaîne immuable dotée d’une intégrité cryptographique
-
Stockage en chunks et téléchargement au moment nécessaire
- Le traitement des gros fichiers et des workspaces utilise le stockage en chunks et l’hydratation à la demande
- Les fichiers sont stockés sous forme de chunks réutilisables et exploitent une récupération basée sur un index
- Cela réduit les doublons et améliore l’efficacité des mises à jour et des transferts de gros actifs binaires
- Le workspace peut rester léger en ne récupérant que les données de fichiers nécessaires
- Avec un workspace sparse, il n’est pas nécessaire de télécharger toutes les données dès le départ
-
Serveur et modèle de branches
- L’architecture serveur est une architecture orientée services avec mise en cache
- La mise en cache en amont d’un durable storage aide à augmenter le débit pour les grandes équipes et les grands dépôts
- Les branches fonctionnent comme des références mutables légères, avec un faible coût de création et de bascule, sans duplication des données sous-jacentes
Dépôts publics et documentation
- Epic Games publie Lore en open source complet sous licence MIT
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- La documentation et les documents de conception du système sont disponibles sur Lore docs et le system design doc
2 commentaires
Avis de Hacker News
Pour ajouter un peu de contexte aux lecteurs de HN qui n’ont jamais fait de jeux vidéo : ce n’est pas un outil qui cherche à concurrencer Git dans le développement logiciel général, mais plutôt Perforce dans le développement de jeux
Git convient aux fichiers textuels comme le code, mais il est très mauvais pour la collaboration sur des fichiers non textuels comme les textures, les modèles 3D ou les fichiers audio. Par exemple, il n’existe pas de façon raisonnable de fusionner des modifications asynchrones faites par deux artistes, donc il peut être nécessaire de mettre un verrouillage exclusif sur un asset pendant qu’un artiste l’édite
Le leader de facto dans ce domaine est le système propriétaire Perforce(https://www.perforce.com/products/helix-core). D’après mes amis développeurs de jeux, Perforce est excellent quand tout fonctionne bien, mais il présente aussi suffisamment de points de friction pour nécessiter l’administration d’un ingénieur outils et parfois des corrections manuelles. Git LFS est aussi une alternative, mais sur des projets d’équipe de plus de 3 ou 4 personnes, tout le monde semble préférer Perforce
Avec P4, on peut restreindre l’accès à certains répertoires aux seules personnes ayant signé les NDA nécessaires, tandis qu’avec Git, c’est tout ou rien. On pourrait peut-être bricoler quelque chose avec des sous-modules, mais si le dépôt n’a pas été conçu comme ça dès le départ, cela implique de bouleverser fortement sa structure
git clone, c’est-à-direp4 sync, peut représenter des téraoctetsGit est faible pour gérer des assets binaires de cette taille, textures, modèles, sons, etc.
Si vous avez un asset souvent mis à jour au début du développement, vous en paierez le coût de stockage pendant toute la durée de vie du dépôt. C’est fréquent en développement de jeux. La plupart des assets changent plusieurs fois au début, puis une fois finalisés, on n’y touche plus jamais
En poussant des changements sur Github aujourd’hui, je pensais encore à quel point l’UI de Git est peu conviviale
Des sorties comme
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltasveulent peut-être dire quelque chose aux utilisateurs hardcore de Git, mais pour la plupart des gens, c’est du pur charabia. C’est quoi au juste la « compression delta », pourquoi faudrait-il savoir combien de threads sont utilisés, et il est difficile de comprendre ce que signifient « objets », objets « local » ou « pack-reused »À en juger par la documentation, Lore semble gérer cette partie un peu mieux. Cela ressemble à
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch main-v. C’est probablement juste que personne n’y a touché, et qu’on a appris à l’ignorer depuis des décenniesLes objets sont référencés par des arbres, et les arbres ne sont au fond que des répertoires. Les arbres sont ensuite référencés par des commits ou des tags pour former un DAG, et les pointeurs nommés qui désignent différents points de ce graphe sont les branches et les références de tags : https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Garder énormément d’objets libres est très inefficace, donc Git regroupe périodiquement les objets en packs. Pour économiser de l’espace, il compare aussi les objets entre eux à l’intérieur d’un pack pour les compresser, c’est ce qu’on appelle la compression delta : https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
Lors d’un push ou d’un pull, le protocole de transport Git énumère les objets possédés par les deux côtés et ne transfère que les différences. En plus de cela, il applique une compression delta des objets qui ne sont pas encore packés des deux côtés pour économiser de l’espace : https://github.com/git/git/blob/master/Documentation/technic...
Git est un projet open source créé par des geeks, donc il affiche toutes ces informations. On peut simplement les ignorer. Et si vous voulez vraiment comprendre, tout est documenté dans le livre Git et le répertoire de documentation liés ci-dessus
Petit à petit, ça commence à faire sens. Du point de vue de l’UI, c’est une grande amélioration par rapport à Git. En revanche, le workflow de branches demande un peu de temps d’adaptation
Je recommande vivement d’aller regarder directement le répertoire
.git. Après ça, les besoins de support Git pour les nouveaux employés tombent pratiquement à zéroCette annonce est particulièrement très prometteuse pour le développement de jeux avec Unreal. Pour d'autres usages, ça ne m'intéresse pas tant que ça.
Perforce a clairement besoin d'un concurrent. Si Perforce est l'acteur historique dominant, ce n'est pas parce qu'il est exceptionnellement simple à utiliser ou à administrer. Rien que pour le travail sur les branches, par exemple, Git est en réalité bien plus simple.
Si P4 est souvent préféré dans le développement de jeux, c'est pour les raisons déjà mentionnées dans d'autres commentaires : la prise en charge des gros projets, les permissions, le verrouillage de fichiers, etc. Une autre raison essentielle est que P4 est très bien pris en charge dans Unreal Engine. Ce n'est pas parfait, mais comme c'est l'outil utilisé en interne par Epic, c'est le système de gestion de versions le mieux pris en charge. Le plugin Git, comme Epic ne l'utilise pas en interne, est douloureusement inachevé.
J'espère donc que Lore bénéficiera d'une prise en charge de premier ordre. Si le support d'Unreal avait été meilleur, j'aurais recommandé Git bien plus souvent. Pour situer le contexte, je travaille dans le développement de jeux depuis presque 20 ans, dans des entreprises allant de 2 à 200 personnes, avec toutes sortes de moteurs et de systèmes de gestion de versions. Je préfère Git là où c'est possible, mais avec Unreal seulement pour de petits projets ou avec des coéquipiers très à l'aise techniquement. Il faut simplement choisir l'outil adapté au travail et à l'équipe.
https://github.com/EpicGames/UnrealEngine/pull/14630
Dans mon précédent studio de jeux, on devait utiliser Perforce, ou plus précisément Helix Core Cloud, qui est de facto le standard du secteur auquel la plupart des métiers créatifs sont déjà habitués. Les programmeurs n'aiment pas ça, mais dans l'industrie du jeu, ce ne sont pas eux qui ont la main. C'est aussi le choix par défaut sûr et éprouvé pour travailler avec Unreal Engine 5.
Cela dit, ça fait vieux. Comme nous étions petits et ne voulions pas d'auto-hébergement, nous avons utilisé tôt le service cloud de Perforce, et l'expérience a été assez bancale. Il fallait créer un compte Azure pour accéder au service, et pour modifier des choses comme les triggers, il fallait passer par le support. Quand on vient du monde de GitHub ou d'autres produits SaaS, on sent que c'est une tentative d'habiller un vieux modèle avec une nouvelle coque.
La voie Git LFS a bien un certain support officieux, mais si ça se complique, il faut se débrouiller soi-même. Epic n'aide pas beaucoup sur ce point. Surtout si l'objectif est un support officiel complet dans le moteur, la concurrence dans ce domaine est la bienvenue.
J'ai écrit un billet expliquant pourquoi la fusion de fichiers n'est pas courante dans le développement de jeux, pour les gens venus du développement centré sur le texte : https://www.kuril.in/blog/why-game-devs-dont-merge-files/
Je viens de reprendre une équipe qui utilisait Git, et même si je sais que Git est le système de gestion de versions préféré de tout le monde, pour le jeu c'est presque le pire choix possible. Avec Git, on mesurait le temps de revue des assets en heures ; avec Perforce, en secondes. Ce n'est pas une blague.
Certains outils intéressants qu'utilise UE5, comme Horde ou UBA, exigent Perforce.
Mais Perforce a profité de sa position dans le secteur sans rien faire. C'est extrêmement cher, et il n'existe même pas vraiment d'offre d'hébergement gérée. Il faut l'héberger soi-même, et même si c'est mieux pour les performances, la maintenance après l'installation initiale est un vrai cauchemar. On voit bien qu'ils essaient de faire quelque chose, mais sans direction claire, et presque tout ce qu'ils ont fait va à l'encontre du bon sens ou de leur base d'utilisateurs. Le produit cœur change sans cesse de nom, sans réelle amélioration.
C'est une leçon sur la façon dont un logiciel propriétaire peut devenir une prison. J'aimerais utiliser un meilleur outil de revue de code que Swarm, intégrer le SSO sans d'étranges hooks LUA qui provoquent des segfaults sur ma machine, et faire tourner un backend de stockage distribué au lieu de dépendre d'énormes SSD et de sauvegardes de journal. Même la licence est liée à l'adresse IP du serveur principal, ce qui empêche toute restauration depuis une sauvegarde.
C'est une technologie oubliée, et l'entité qui dirige cette entreprise ressemble à un zombie.
Je ne sais pas si les questions de permissions ont été réglées, ni si ce modèle hybride de gestion de versions distribué/centralisé — où le checkout au niveau du fichier interagit avec un workflow traditionnel fondé sur les branches — a été vraiment clarifié.
D’après la FAQ, il ne s’agit en fait pas d’un produit entièrement nouveau, mais de quelque chose qui n’est rendu open source que maintenant
« Lore, auparavant appelé Unreal Revision Control, est le système de gestion de versions intégré à l’UEFN (Unreal Editor for Fortnite), utilisé jusqu’ici par les créateurs pour gérer les versions de leurs îles. Les équipes internes d’Epic l’adoptent aussi progressivement, et il est en cours d’implémentation comme dépôt backend du pipeline de cook d’UEFN, afin de remplacer la couche intermédiaire de stockage existante, d’éliminer les transferts de fichiers dupliqués et de réduire fortement le délai entre la publication de modifications et le moment où elles deviennent jouables. »
Il est surprenant qu’Epic ait choisi Rust plutôt qu’Epic C++ ou Verse. Je me demande pourquoi
Quant au choix de Rust plutôt que Verse, c’est probablement parce que cette tâche ne convenait pas à Verse. Ce serait sans doute vrai même si Simon travaillait sur Verse. Et si ce n’est pas Haskell mais Rust, c’est probablement pour des raisons de performance. DARCS non plus ne s’est jamais largement imposé, en partie à cause de problèmes de performance
En plus, cela reviendrait à se lier à tous les problèmes et à toutes les lenteurs du moteur. Epic a déjà fait cette erreur avec Epic Games Launcher. C’est en pratique une forme d’exécution d’une instance du moteur, et c’est une source majeure de nombreux problèmes
Si l’on compare Verse et Rust, Verse est utilisé dans l’expérience UEFN, mais reste encore loin d’un état de production. De plus, il est intrinsèquement lié à l’UEFN. On ne peut pas non plus télécharger un compilateur autonome ou un REPL
Bien sûr, sauf s’il est rendu public parce qu’ils ont décidé d’arrêter son développement, mais cela ne semble pas être le cas ici
Full-surface API est une fonctionnalité que personne ici n’a mentionnée. Je me demande si c’est une pique visant le fait que Git ne fournit pas délibérément de bibliothèque liable. J’avais déjà vu ce billet : https://news.ycombinator.com/item?id=48470604
porcelainpour interagir avec les programmes. Ce n’est pas une forme liable, mais cela reste une APILe postulat est que Git-LFS n’est pas terrible, et qu’il faudrait donc créer de zéro en Rust un nouveau système de gestion de versions de données. Je suis globalement d’accord avec ce postulat, mais il existe déjà pas mal de systèmes matures de gestion de versions de données qui utilisent en interne des techniques similaires
Pachyderm(Go) : https://github.com/pachyderm/pachyderm
XetHub(acquis par HuggingFace) : https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go) : https://github.com/treeverse/lakeFS
Oxen(Rust) : https://github.com/Oxen-AI/Oxen
On vit peut-être désormais à l’époque où, grâce à l’IA, tout le monde peut faire du vibe coding d’un système de gestion de versions avec adressage par contenu et déduplication par blocs en Rust
Blague à part, Lore a vraiment l’air très réussi. Ce qui est intéressant, c’est que des domaines et des industries différents semblent avoir des problèmes similaires, sans qu’il y ait beaucoup d’échanges d’idées. Dans ce cas, l’IA comme le jeu vidéo ont tous deux besoin de systèmes de stockage pour la gestion de versions de gros fichiers binaires à grande échelle. Il semble y avoir beaucoup d’occasions de partager des idées, et le manque actuel d’échanges peut en soi créer une opportunité
Cette seule différence peut suffire à exiger des architectures de stockage différentes
Une partie du problème venait, selon moi, des compromis nécessaires pour conserver Git lui-même et un stockage hybride. C’est pourquoi je suis content que ce système de gestion de versions n’utilise pas Git. xethub a aussi commencé à sortir une version de son produit qui n’utilise pas Git, mais je n’ai pas eu l’occasion de l’essayer
J’ai aussi essayé oxen, et au début ce n’était pas mal, mais je suis vite tombé sur d’étranges problèmes liés à l’état du dépôt, sans chercher à les déboguer en profondeur. Après avoir utilisé tous ces systèmes, il est devenu clair qu’aucun n’est satisfaisant à 100 %, et que faire un Git pour les données n’est pas un problème anodin
Je me demande quelle entreprise déploiera réellement ce système, par exemple dans les 2 ans
Helix et Perforce font ce travail depuis des décennies et on peut leur faire confiance, parce que cela fait partie de leur cœur de métier. On sait qu’ils continueront à maintenir leur produit pendant encore un bon moment
Mais si Epic abandonnait ce projet demain, cela n’aurait aucun impact sur son activité. Au contraire, récupérer ces ressources de développement pourrait même l’aider dans son business
C’est un peu le même problème que de se demander pourquoi on croirait que Cloudflare continuera à investir dans EmDash sur le long terme. Cloudflare ne s’intéresse pas aux CMS. Offrir la meilleure expérience possible aux lecteurs, aux auteurs et aux propriétaires de sites n’est pas son activité. C’est presque une activité annexe, sans grand rapport avec son cœur de métier
Il existe dans cet espace depuis longtemps un concurrent assez correct appelé PlasticSCM, et c’est toujours le cas aujourd’hui. Unity l’a acquis il y a quelques années, mais Unity n’a pas été un bon gestionnaire
Ils auraient dû le rendre open source comme le fait Epic, mais ils ont préféré le traiter comme une entité avec responsabilité de résultat. Je me demande combien cela contribue réellement aux finances de Unity
Avis sur Lobste.rs
Le fait que ce soit optimisé pour les projets jeu/divertissement qui gèrent à la fois du code et de gros assets binaires me fait dire que, enfin, quelqu’un en a eu assez des décennies de monopole de Perforce et a fini par construire quelque chose
Il me semblait que ce n’était pas le cas quand je l’ai vu la première fois, mais je me demande pourquoi il porte maintenant le tag vibecoding
Par exemple, expliquer que « Mercurial et Sapling sont centrés sur l’historique texte alors que Lore est d’abord pensé pour le binaire » est faux. Mercurial aussi repose sur un modèle d’objets binaires sur lequel viennent se greffer des fonctionnalités texte
Ayant participé au développement de Mercurial/Sapling, je pense qu’un LLM peut améliorer la rigueur en signalant des alternatives qu’une équipe aurait manquées, mais ce document m’a déçu. Les décisions elles-mêmes ont beaucoup d’atouts, mais j’aurais aimé un document rédigé avec bien plus de rigueur
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
Est-ce que ce serait le premier projet Rust rendu public par Epic Games ?
Entre ça et les récentes annonces autour du système de contrôle de version de Cursor, on dirait qu’en ce moment tout le monde veut créer son propre VCS
Je suis le seul à avoir eu comme première pensée : « est-ce que ça ne devrait pas être hébergé sur lore ? »