스크립트
00:00:00Epic Games a créé son propre système de gestion de versions parce qu'ils en avaient assez de Git.
00:00:05Ils l'ont construit en Rust puis l'ont rendu gratuit. Ça s'appelle Lore. Donc oui,
00:00:10l'entreprise derrière Fortnite a construit une alternative à Git. Mais Git reste excellent,
00:00:15évidemment. Mais Git a été conçu pour le code. Principalement des fichiers texte, beaucoup de petits fichiers,
00:00:21des modifications qui tiennent généralement en quelques lignes. Les jeux sont pratiquement l'opposé de ça. Alors
00:00:26comment Lore se compare-t-il à Git et comment l'utiliser ? Découvrons-le.
00:00:35À ce stade, nous avons des textures massives, des fichiers audio, des vidéos, des modèles 3D,
00:00:41et toutes sortes d'actifs binaires qui peuvent peser des centaines de mégaoctets, voire plusieurs gigaoctets chacun. Et
00:00:47une fois que ces fichiers commencent à changer, les choses deviennent vraiment compliquées. Votre dépôt grossit, les clones deviennent plus lents,
00:00:53l'historique devient énorme. Et finalement, quelqu'un dit : “OK, peut-être qu'on devrait utiliser Git LFS”. Git LFS aide,
00:01:01mais c'est aussi ressenti comme une solution de contournement ajoutée à un système qui n'a jamais été conçu pour ce type de données.
00:01:06Ensuite, vous avez des quotas, des limites de bande passante et de vieux actifs qui traînent dans l'historique. Donc
00:01:12beaucoup de studios utilisent Perforce. Et pour être juste, Perforce fonctionne. Il y a une raison pour laquelle tant de studios
00:01:18de jeux l'utilisent, mais c'est cher. Ça peut devenir compliqué. Et une fois que votre configuration devient assez grande,
00:01:24quelqu'un finit généralement par être la personne qui maintient tout en vie. C'est ce que Lore a été
00:01:29conçu pour régler. Si vous aimez coder des outils pour accélérer votre flux de travail, assurez-vous de vous abonner.
00:01:35Nous publions des vidéos tout le temps. Très bien. Maintenant, au lieu de juste parler de Lore,
00:01:39c'est cool. Laissez-moi le faire fonctionner. Laissez-moi vous montrer comment ça marche. La démo commence par une commande
00:01:44d'installation et un flag de démo, que nous allons exécuter ici. Et c'est tout. Quelques secondes plus tard,
00:01:51j'ai un serveur Lore qui tourne localement. Pas de compte cloud, pas de clé, pas de configuration de certificat. Il tourne ici
00:01:57sur ces ports. Et juste pour prouver qu'il est bien vivant, je peux simplement appeler l'endpoint de santé juste
00:02:03ici. Et je vais faire ça sur ce terminal. Et voilà. Il est vivant. Il tourne.
00:02:08Il n'y a aucun service d'arrière-plan que je dois connecter manuellement. Aucun jeton d'authentification à générer. Il n'y a
00:02:14pas d'assistant de configuration. Ça démarre simplement. Maintenant, laissez-moi créer un dépôt. Donc je vais créer un dossier,
00:02:22d'accord ? Et nous allons créer ce dépôt. Et maintenant je vais créer un gros fichier binaire
00:02:27et le commiter, d'accord ? C'est juste un fichier fictif, d'accord ? Mais créons un fichier plus gros. J'exécute
00:02:32DD ici pour la duplication de données. Maintenant, au lieu de traiter ce fichier de 100 mégaoctets comme un seul objet énorme,
00:02:40Lore le découpe en petits morceaux. Ces morceaux sont hachés, compressés avec Z standard, et stockés dans un
00:02:47arbre de Merkle adressé par contenu. Si la majeure partie du fichier reste identique, Lore n'a pas besoin de sauvegarder une autre copie complète
00:02:52de l'ensemble. Il peut réutiliser les morceaux qu'il a déjà et ne stocker que les parties qui ont changé.
00:02:58C'est bien plus adapté à un gros actif binaire. Juste après la fin du commit, vous pouvez voir l'état
00:03:04local qui a été créé sur le disque. Il y a maintenant un répertoire Lore ici avec la configuration et les
00:03:10métadonnées. Très bien, maintenant que nous avons ça, créons une branche. OK, je peux exécuter Lore branch create
00:03:17et nommer la branche. Ça fonctionne à peu près comme Git. Donc basculons dessus. Faisons une petite
00:03:24modification ici. Je vais créer un fichier texte rapide et le commiter dans cette branche. Donc je modifie, ensuite on peut le stager,
00:03:31et ensuite on peut le commiter, d'accord ? Le flux est globalement le même que Git. Maintenant je vais basculer
00:03:37en arrière. Et c'était pratiquement instantané. L'autre chose importante est que rien de tout cela ne nécessitait un
00:03:44aller-retour vers un serveur. Stager, commiter, créer une branche, basculer, diff, tout ça se passe localement. Donc
00:03:50même si Lore a un serveur central, votre travail quotidien semble toujours rapide et vous pouvez continuer à
00:03:56travailler hors ligne. Ça donne juste une impression de légèreté. Maintenant, la question devient, OK,
00:04:02où vont toutes les données ? Dans cette démo ici, tout est temporaire. Donc quand j'arrête le serveur,
00:04:08les données disparaissent. C'est parce que j'utilise juste le mode démo. Dans une vraie configuration, vous exécuteriez Lore server
00:04:15avec un fichier de configuration et un stockage persistant. Les mêmes commandes CLI et le flux de travail local restent exactement
00:04:21les mêmes. Vous pointez simplement le serveur vers de vrais répertoires ou un stockage d'objets au lieu de jeter
00:04:27ce dossier temporaire. Maintenant avec Git, Git vous donne un historique des snapshots de projet. Bien qu'à l'intérieur
00:04:34il effectue beaucoup d'optimisations intelligentes, Lore est conçu autour du découpage et de la déduplication dès
00:04:40le départ. Donc pour un projet lourd en actifs, il n'a pas besoin de traiter chaque nouvelle version du fichier
00:04:47comme un objet géant complètement séparé. Lore peut aussi hydrater les fichiers à la demande afin que vous puissiez travailler avec
00:04:53le dépôt contenant une énorme quantité de données sans télécharger chaque actif depuis le premier jour.
00:04:59Vous téléchargez ce dont vous avez réellement besoin pour la partie du projet sur laquelle vous travaillez.
00:05:03Maintenant, une chose qui est un peu confuse ici quand Lore a été lancé était de savoir si c'est centralisé ou
00:05:08distribué. C'est centralisé. Il y a un serveur de référence, mais la plupart du travail que nous faisons
00:05:15se passe localement. Donc en pratique, il se situe quelque part entre Perforce et Git. Vous obtenez un contrôle central
00:05:22et une gestion des accès, mais les opérations locales semblent toujours rapides et ne dépendent pas du fait que le serveur soit
00:05:28disponible à chaque seconde. Il y a aussi de belles différences. Lore est sous licence MIT, le protocole
00:05:34est open source, et il existe des SDK pour plusieurs langages, ce qui rend beaucoup plus facile le scripting et
00:05:39la construction d'outils autour. Maintenant, c'est probablement un bon moment pour être réaliste. Lore n'est pas quelque chose que je
00:05:45remplacerais demain dans une configuration de production Perforce. C'est encore en pré-1.0. Epic Games dit que les API peuvent changer
00:05:52avant la première version stable, et le projet évolue clairement encore. Il n'y a aussi aucune interopérabilité
00:05:58Git pour le moment, et vous ne pouvez pas juste pointer Lore vers un dépôt Git existant et importer tout
00:06:03l'historique. C'est aussi auto-hébergé. Il n'y a pas de service hébergé où vous créez un compte,
00:06:09poussez votre dépôt, et c'est fini. Et l'application de bureau que vous pourriez voir flotter n'est pas incluse dans la
00:06:15version open source. Ce que vous obtenez, c'est la bibliothèque centrale, le serveur, la CLI et les SDK. Cette interface graphique n'en fait pas
00:06:22partie. Ensuite, bien sûr, la performance. Comment ça performe ? Epic dit que Lore peut gérer d'énormes
00:06:28dépôts sans ralentir comme le font d'autres systèmes. Et Epic a évidemment de l'expérience avec
00:06:33certains très gros projets. Mais pour le moment, la plupart de ces affirmations viennent d'Epic eux-mêmes. Il
00:06:39n'y a pas vraiment de benchmarks indépendants solides encore. Donc la performance semble prometteuse, mais jusqu'à ce qu'on commence vraiment
00:06:45à tester ça, il est difficile de voir comment ça performe. Devriez-vous l'utiliser ? Eh bien, c'est amusant de jouer
00:06:50avec. Faites-vous des jeux ? Construisez-vous des projets massifs ? OK, pour un nouveau projet, peut-être.
00:06:56Si vous voulez juste voir où pourrait aller le contrôle de version pour les gros actifs binaires, ça vaut le coup d'essayer.
00:07:01Testez-le sur quelque chose de non critique, jouez avec, voyez comment ça performe, voyez comment est le flux.
00:07:07Le point le plus important ici n'est pas de savoir si Lore remplacera Git ou Perforce de sitôt. Le point le plus important est que
00:07:14le contrôle de version a cessé d'être un problème résolu une fois que les projets ont commencé à être livrés avec d'énormes quantités de
00:07:19données binaires. Git a gagné pour le texte et les fichiers plus petits. Lore essaie de résoudre quelque chose qui vient après ça.
00:07:27Et honnêtement, qu'il gagne ou non, c'est quand même une direction vraiment cool. Si vous appréciez les conseils
00:07:32et astuces de codage comme celui-ci, assurez-vous de vous abonner à la chaîne Betterstack. On se voit dans une autre vidéo.