O Git não aguenta jogos… Então a Epic criou o Lore

BBetter Stack
컴퓨터/소프트웨어창업/스타트업게임/e스포츠

스크립트

00:00:00A Epic Games criou sua própria versão de sistema de controle por ter se cansado do Git.
00:00:05Eles criaram em Rust e depois o liberaram gratuitamente. Chama-se Lore. Então, sim,
00:00:10a empresa por trás de Fortnite criou uma alternativa ao Git. Mas o Git ainda é ótimo,
00:00:15obviamente. Porém, o Git foi criado para código. Principalmente arquivos de texto, muitos arquivos pequenos,
00:00:21alterações que geralmente são de algumas linhas de cada vez. Jogos são basicamente o oposto disso. Então,
00:00:26como o Lore se compara ao Git e como trabalhamos com ele? Vamos descobrir.
00:00:35Agora, neste ponto, temos texturas massivas, arquivos de áudio, vídeos, modelos 3D,
00:00:41e todos os tipos de ativos binários que podem ter centenas de megabytes ou até vários gigabytes cada. E
00:00:47uma vez que esses arquivos começam a mudar, as coisas ficam realmente bagunçadas. Seu repositório cresce, clones ficam mais lentos,
00:00:53o histórico fica enorme. E eventualmente alguém diz, ok, talvez devêssemos usar o Git LFS. O Git LFS ajuda,
00:01:01mas também parece uma solução paliativa adicionada a um sistema que nunca foi projetado para esse tipo de dado.
00:01:06Aí você tem cotas, limites de largura de banda e ativos antigos permanecendo no histórico. Então,
00:01:12muitos estúdios usam o Perforce. E para ser justo, o Perforce funciona. Existe uma razão pela qual tantos estúdios
00:01:18de jogos o usam, mas é caro. Pode ficar complicado. E assim que sua configuração fica grande o suficiente,
00:01:24alguém geralmente acaba se tornando a pessoa que mantém tudo funcionando. Essa é a coisa que o Lore foi
00:01:29projetado para consertar. Se você gosta de ferramentas de codificação para acelerar seu fluxo de trabalho, certifique-se de se inscrever.
00:01:35Temos vídeos saindo o tempo todo. Tudo bem. Agora, em vez de apenas falar sobre o Lore,
00:01:39é legal. Deixe-me colocá-lo para rodar. Deixe-me mostrar como funciona. A demonstração começa com um comando
00:01:44de instalação e uma flag de demonstração, que vamos executar aqui mesmo. E é isso. Alguns segundos depois,
00:01:51tenho um servidor Lore rodando localmente. Sem conta na nuvem, sem chave, sem configuração de certificado. Está rodando aqui
00:01:57nessas portas. E apenas para provar que está realmente vivo, posso simplesmente acessar o endpoint de integridade aqui
00:02:03mesmo. E vou fazer isso neste terminal. E pronto. Está vivo. Está rodando.
00:02:08Não há serviços em segundo plano que eu precise conectar manualmente. Nenhum token de autenticação para gerar. Não há
00:02:14assistente de configuração. Ele simplesmente inicia. Agora, deixe-me criar um repositório. Então, vou criar uma pasta,
00:02:22certo? E vamos criar este repositório. E agora vou criar um arquivo binário grande
00:02:27e fazer o commit dele, certo? Este é apenas um arquivo fictício, certo? Mas vamos criar um arquivo maior. Estou executando
00:02:32o DD aqui para duplicação de dados. Agora, em vez de tratar aquele arquivo de 100 megabytes como um objeto enorme,
00:02:40o Lore o quebra em pedaços menores. Esses pedaços são hasheados, compactados com Zstandard e armazenados em uma
00:02:47árvore de Merkle endereçada por conteúdo. Se a maior parte do arquivo permanece a mesma, o Lore não precisa salvar outra cópia
00:02:52completa de tudo. Ele pode reutilizar os pedaços que já possui e armazenar apenas as partes que mudaram.
00:02:58Isso é muito mais adequado para um ativo binário grande. Logo após o término do commit, você pode ver o
00:03:04estado local que foi criado no disco. Agora existe um diretório Lore aqui com a configuração e os
00:03:10metadados. Tudo bem, agora que temos isso, vamos criar uma branch. Ok, posso executar Lore branch create
00:03:17e nomear a branch. Funciona quase como o Git. Então, vamos mudar para ela. Vamos fazer uma pequena
00:03:24alteração aqui. Vou criar um arquivo de texto rápido e fazer o commit dele nesta branch. Então eu modifico, depois podemos preparar,
00:03:31e então podemos fazer o commit, certo? O fluxo é praticamente o mesmo do Git. Agora vou mudar
00:03:37de volta. E isso foi basicamente instantâneo. A outra coisa importante é que nada disso exigiu uma
00:03:44viagem a qualquer servidor. Preparar, fazer commit, criar branch, alternar, comparar, tudo isso acontece localmente. Então,
00:03:50mesmo que o Lore tenha um servidor central, seu trabalho diário ainda parece rápido e você pode continuar
00:03:56trabalhando offline. Isso faz com que tudo pareça leve. Agora a pergunta se torna, ok,
00:04:02para onde vão todos os dados? Nesta demonstração aqui, tudo é temporário. Então, quando paro o servidor,
00:04:08os dados desaparecem. Isso porque estou apenas usando o modo de demonstração. Em uma configuração real, você executaria o servidor Lore
00:04:15com um arquivo de configuração e armazenamento persistente. Os mesmos comandos da CLI e fluxo de trabalho local permanecem exatamente
00:04:21os mesmos. Você só está apontando o servidor para diretórios reais ou armazenamento de objetos em vez de descartar
00:04:27aquela pasta temporária. Agora, com o Git, o Git lhe dá um histórico de snapshots do projeto. Embora
00:04:34internamente ele faça muitas otimizações inteligentes, o Lore é projetado em torno de fragmentação e desduplicação desde
00:04:40o início. Então, para um grande projeto pesado em ativos, ele não precisa tratar cada nova versão do arquivo
00:04:47como um objeto gigante completamente separado. O Lore também pode hidratar arquivos sob demanda para que você possa trabalhar
00:04:53com o repositório contendo uma enorme quantidade de dados sem baixar cada ativo desde o primeiro dia.
00:04:59Você baixa o que realmente precisa para a parte do projeto em que está trabalhando.
00:05:03Agora, uma coisa que é um pouco confusa quando o Lore foi lançado é se ele é centralizado ou
00:05:08distribuído. Ele é centralizado. Existe um servidor de registro, mas a maior parte do trabalho que estamos fazendo é
00:05:15acontecendo localmente. Então, na prática, ele fica em algum lugar entre o Perforce e o Git. Você obtém controle central
00:05:22e gerenciamento de acesso, mas as operações locais ainda parecem rápidas e não dependem do servidor estar
00:05:28disponível a cada segundo. Existem algumas diferenças legais também. O Lore é licenciado sob MIT, o protocolo
00:05:34é de código aberto e existem SDKs para vários idiomas, o que torna muito mais fácil criar scripts e
00:05:39construir ferramentas em torno dele. Agora, provavelmente é um bom ponto para ser realista aqui. O Lore não é algo que eu
00:05:45substituiria em uma configuração de produção de Perforce amanhã. Ainda está na versão pré-1.0. A Epic Games diz que as APIs podem mudar
00:05:52antes do primeiro lançamento estável, e o projeto está claramente ainda evoluindo. Também não há interoperabilidade
00:05:58com o Git agora, e você não pode simplesmente apontar o Lore para um repositório Git existente e trazer o
00:06:03histórico completo. Ele também é auto-hospedado. Não existe um serviço hospedado onde você cria uma conta,
00:06:09faz push do seu repositório e pronto. E o aplicativo de desktop que você pode ver por aí não está incluído no
00:06:15lançamento de código aberto. O que você ganha é a biblioteca principal, o servidor, a CLI e os SDKs. Essa GUI não é
00:06:22parte disso. Então, é claro, o desempenho. Como isso se comporta? A Epic diz que o Lore pode lidar com grandes
00:06:28repositórios sem diminuir a velocidade como outros sistemas fazem. E a Epic obviamente tem experiência com
00:06:33alguns projetos muito grandes. Mas agora, a maioria dessas alegações vem da própria Epic. Não
00:06:39existem benchmarks independentes sólidos ainda. Então o desempenho parece promissor, mas até que realmente
00:06:45comecemos a testar isso, é difícil ver como ele se comporta. Você deveria usá-lo? Bem, é divertido brincar
00:06:50com ele. Você está criando jogos? Você está construindo projetos massivos? Ok, para um novo projeto, talvez.
00:06:56Se você apenas quer ver para onde o controle de versão para grandes ativos binários pode estar indo, vale a
00:07:01pena tentar. Teste-o em algo não crítico, brinque com ele, veja como ele se comporta, veja como é o fluxo.
00:07:07O ponto mais importante aqui não é se o Lore substitui o Git ou o Perforce tão cedo. O ponto mais importante é que
00:07:14o controle de versão deixou de ser um problema resolvido quando projetos começaram a ser enviados com grandes quantidades de
00:07:19dados binários. O Git venceu para texto e arquivos menores. O Lore está tentando resolver algo que vem depois disso.
00:07:27E honestamente, se ele vencer ou não, ainda é uma direção muito legal. Se você gosta de dicas e truques
00:07:32de codificação como este, certifique-se de se inscrever no canal Betterstack. Nos vemos em outro vídeo.

핵심 요약

O Lore é uma solução de controle de versão centralizado criada pela Epic Games para superar as limitações do Git em gerenciar grandes arquivos binários, utilizando fragmentação e desduplicação para manter o fluxo de trabalho local rápido.

하이라이트

  • A Epic Games desenvolveu o Lore, um sistema de controle de versão escrito em Rust, como alternativa ao Git para lidar com grandes volumes de ativos binários.

  • O Lore utiliza uma estrutura de árvore de Merkle com fragmentação de dados e compactação Zstandard para armazenar apenas as alterações em ativos massivos, economizando espaço em disco.

  • Operações como criar commits, branches e comparar dados no Lore ocorrem localmente, mantendo a velocidade do fluxo de trabalho mesmo com um servidor central.

  • O sistema permite hidratar arquivos sob demanda, evitando a necessidade de baixar todo o histórico ou o repositório completo para trabalhar em partes específicas.

  • O Lore possui licenciamento MIT, código aberto e SDKs para diversas linguagens, facilitando a integração em ferramentas personalizadas.

  • O projeto está atualmente em versão pré-1.0, sem interoperabilidade com o Git e sem um serviço hospedado, exigindo auto-hospedagem para uso.

타임라인

Limitações do Git e do Perforce

  • O Git foi projetado para arquivos de texto pequenos, tornando-se ineficiente para ativos massivos como texturas e modelos 3D.
  • O Git LFS é uma solução paliativa com limitações de cota e largura de banda.
  • O Perforce é a escolha comum da indústria, mas apresenta custos elevados e complexidade na manutenção.

Jogos modernos dependem de arquivos que podem chegar a vários gigabytes, o que causa lentidão em clones e um histórico inchado no Git. Embora estúdios utilizem o Perforce para contornar esses problemas, o gerenciamento dessa infraestrutura exige dedicação constante e altos investimentos financeiros.

Funcionamento técnico do Lore

  • O Lore fragmenta arquivos binários em partes menores, que são processadas via árvore de Merkle endereçada por conteúdo.
  • A compactação Zstandard reduz o volume de armazenamento ao reutilizar partes de arquivos que não foram alteradas.
  • Comandos comuns de controle de versão rodam localmente, garantindo agilidade e suporte a trabalho offline.

A instalação do servidor Lore é imediata e não requer chaves, nuvem ou certificados para testes locais. Ao realizar o commit de um arquivo, o sistema quebra o dado em pedaços e armazena apenas as alterações, tornando o processo muito mais eficiente do que tratar cada versão como um objeto completo e separado.

Arquitetura e estado atual do projeto

  • O Lore utiliza um modelo centralizado com servidor de registro, ocupando um espaço entre o Perforce e o Git.
  • O sistema oferece hidratação sob demanda para trabalhar apenas com os dados necessários do projeto.
  • Por estar na versão pré-1.0, o software não possui interoperabilidade com o Git e requer auto-hospedagem.

O projeto oferece a biblioteca principal, servidor, CLI e SDKs, mas exclui o aplicativo de desktop da versão de código aberto. Embora as promessas de desempenho da Epic Games para grandes repositórios sejam promissoras, ainda não existem benchmarks independentes que comprovem a eficiência em produção, tornando o sistema ideal para testes em projetos não críticos por enquanto.

커뮤니티 글

모든 글 보기