- Lore, mantido pela Epic Games, é um sistema de controle de versão open source de próxima geração voltado a projetos que lidam ao mesmo tempo com código e grandes ativos binários
- Ele pode começar rápido em modo local e depois escalar conforme a necessidade, oferecendo dados compartilhados e reutilizáveis e downloads no momento necessário para dar suporte a grandes repositórios e equipes
- Usa um repositório centralizado baseado em endereçamento por conteúdo, representando o estado do repositório e o histórico de mudanças com Merkle tree e uma cadeia imutável de revisions
- Arquivos grandes são armazenados em chunks reutilizáveis, e com sparse workspace e hydration sob demanda não é preciso baixar todos os dados desde o início
- Foi lançado sob licença MIT e oferece CLI, APIs para C/C++, C#, Rust, Go, Python e JavaScript, além de vários repositórios de SDK
Controle de versão para código e grandes ativos juntos
- Lore é um sistema de controle de versão open source de próxima geração mantido pela Epic Games
- Foi projetado com foco em alta escalabilidade em volume de dados, tamanho de equipe, distribuição da equipe e tamanho de repositório
- É otimizado para projetos que usam ao mesmo tempo código e grandes ativos binários
- Projetos das indústrias de jogos e entretenimento são apresentados como exemplo
- Atende simultaneamente às necessidades de colaboração de desenvolvedores e artistas
- É possível começar em modo local em poucos minutos e depois expandir conforme a necessidade
- Fornece a base para que equipes criem fluxos de trabalho de colaboração rápidos, intuitivos e práticos
Estrutura para escalabilidade e tratamento de arquivos grandes
-
Dados compartilhados e APIs
- Os principais recursos são organizados com foco em escalabilidade e tratamento de grandes ativos
- O objetivo é escalar sem perda de desempenho com dados compartilhados e reutilizáveis e downloads no momento necessário
- É possível criar, gerenciar e sincronizar branches rapidamente
- Há acesso um a um a todos os recursos do Lore por meio da CLI
- APIs para C/C++, C#, Rust, Go, Python e JavaScript oferecem suporte a extensão, personalização e integração
-
Repositório baseado em endereçamento por conteúdo
- A estrutura do repositório é um sistema centralizado de controle de versão content-addressed
- Os dados do repositório são armazenados e referenciados por hash de conteúdo, sendo representados por uma Merkle tree
- Isso permite comparação rápida, verificação de integridade e reutilização de dados entre histórico e branches
- A assinatura hash de uma revision deriva do estado da revision, incluindo o hash da revision pai e os hashes dos dados incluídos
- Essa estrutura forma uma cadeia imutável com integridade criptográfica
-
Armazenamento em chunks e download no momento necessário
- O tratamento de arquivos grandes e workspaces usa armazenamento em chunks e hydration sob demanda
- Os arquivos são armazenados em chunks reutilizáveis e usam consulta baseada em índice
- Isso reduz duplicação e torna mais eficientes as atualizações e a transferência de grandes ativos binários
- O workspace pode permanecer leve ao trazer apenas os dados de arquivo necessários
- Com sparse workspace, não é necessário baixar todos os dados desde o início
-
Servidor e modelo de branches
- A estrutura de servidor é uma arquitetura baseada em serviços com cache
- O cache à frente do durable storage ajuda a ampliar a taxa de processamento para grandes equipes e grandes repositórios
- As branches funcionam como referências mutáveis leves, com baixo custo de criação e troca, sem duplicação dos dados-base
Repositórios públicos e documentação
- A Epic Games lançou o Lore como open source completo sob licença MIT
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- A documentação e o documento de arquitetura do sistema estão disponíveis em Lore docs e system design doc
2 comentários
Comentários do Hacker News
Para dar contexto aos leitores do HN que nunca fizeram jogos: isto não é uma ferramenta para competir com o Git no desenvolvimento de software em geral, e sim com o Perforce no desenvolvimento de jogos
O Git é bom para arquivos baseados em texto, como código, mas é muito fraco para colaboração em arquivos não textuais, como texturas, modelos 3D e arquivos de áudio. Por exemplo, não existe uma forma razoável de mesclar edições assíncronas de dois artistas, então pode ser necessário colocar um bloqueio exclusivo em um asset enquanto um artista o estiver editando
O líder de fato nessa área é o sistema proprietário Perforce(https://www.perforce.com/products/helix-core). Segundo amigos desenvolvedores de jogos, o Perforce é excelente quando funciona bem, mas também tem atritos suficientes para precisar ser administrado por engenheiros de ferramentas e ocasionalmente corrigido manualmente. Git LFS também é uma alternativa, mas em projetos de equipe com mais de 3 ou 4 pessoas, todos acabam preferindo o Perforce
No P4, dá para restringir o acesso a diretórios específicos apenas a quem assinou os NDAs necessários, mas no Git é tudo ou nada. Dá para montar algo com submódulos, mas se o repositório não foi projetado assim desde o começo, isso exige uma grande reestruturação
git clone, ou seja, ump4 sync, pode chegar a terabytesO Git é fraco para lidar com assets binários, texturas, modelos, sons etc. nessa escala
Se houver um asset atualizado com frequência no início do desenvolvimento, você acaba pagando por esse armazenamento durante toda a vida útil do repositório. Isso é comum no desenvolvimento de jogos. A maioria dos assets muda várias vezes no começo e, quando fica pronta, nunca mais é tocada
Hoje, enquanto eu fazia push de mudanças no Github, pensei de novo em como a UI do Git não é nada amigável
Saídas como
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltaspodem dizer algo para usuários hardcore de Git, mas para a maioria das pessoas são puro galimatias. O que exatamente é “compressão delta”, por que eu precisaria saber quantas threads estão sendo usadas, e o que significam “objetos”, objetos “local” ou “pack-reused” é difícil de entenderPela documentação, o Lore parece lidar um pouco melhor com isso. Fica algo como
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch main-v. Provavelmente ninguém nunca mexeu nisso, e durante décadas só aprendemos a ignorarOs objetos são referenciados por árvores, e árvores são basicamente diretórios. Essas árvores, por sua vez, são referenciadas por commits ou tags, formando um DAG, e os ponteiros nomeados que apontam para vários desses pontos são as referências de branches e tags: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Manter um monte de objetos soltos é muito ineficiente, então o Git periodicamente agrupa os objetos em packs. Para economizar espaço, ele comprime os objetos dentro do pack comparando uns com os outros, e isso é a compressão delta: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
Ao fazer push ou pull, o protocolo de transporte do Git enumera quais objetos cada lado possui e transfere apenas a diferença. Além disso, ele aplica compressão delta aos objetos que ainda não foram agrupados em packs nos dois lados para economizar espaço: https://github.com/git/git/blob/master/Documentation/technic...
O Git é um projeto open source feito por nerds, então ele mostra todas essas informações. Você pode simplesmente ignorá-las. Se realmente quiser entender, tudo está documentado no livro do Git e no diretório de documentação linkados acima
Aos poucos está fazendo sentido para mim. Do ponto de vista de UI, é uma grande melhora em relação ao Git. Só que o fluxo de trabalho com branches leva um tempo para se acostumar
Recomendo fortemente olhar diretamente dentro do diretório
.git. Depois disso, a demanda por suporte de Git para novos funcionários cai praticamente a zeroEste anúncio parece especialmente promissor para o desenvolvimento de jogos com Unreal. Para outros usos, não me chama tanto a atenção
O Perforce claramente precisa de um concorrente. O motivo de o Perforce ser o veterano dominante não é que ele seja excepcionalmente simples de usar ou administrar. Por exemplo, só olhando para trabalho com branches, o Git na prática é muito mais simples
Os motivos de o P4 ser frequentemente preferido no desenvolvimento de jogos incluem, como outros comentários já citaram, suporte a projetos grandes, permissões, bloqueio de arquivos etc. Outro motivo central é que o P4 é muito bem suportado dentro do Unreal Engine. Não é perfeito, mas como é a ferramenta que a Epic usa internamente, é o sistema de controle de versão com melhor suporte. O plugin de Git é dolorosamente inacabado porque a Epic não o usa internamente
Por isso, espero que o Lore receba suporte de primeira linha. Se o suporte do Unreal fosse melhor, eu recomendaria Git com muito mais frequência. Para dar contexto, trabalho com desenvolvimento de jogos há quase 20 anos e já passei por empresas de 2 a 200 pessoas, além de todo tipo de engine e sistema de controle de versão. Prefiro Git onde ele pode ser usado, mas no Unreal isso geralmente só vale para projetos pequenos ou quando a equipe é mais familiarizada com tecnologia. Basta escolher a ferramenta certa para o trabalho e para a equipe
https://github.com/EpicGames/UnrealEngine/pull/14630
No estúdio de jogos anterior, tivemos que usar Perforce, mais especificamente o Helix Core Cloud, que é o padrão de fato da indústria com o qual a maior parte das áreas criativas já está acostumada. Os programadores não gostam, mas quem dita o rumo na indústria de jogos não são os programadores. Também é a opção padrão segura e comprovada para usar com Unreal Engine 5
Ainda assim, ele mostra a idade. Éramos pequenos e não queríamos self-hosting, então acabamos usando o serviço de nuvem da Perforce logo no começo, e a experiência foi bem truncada. Para acessar o serviço, era preciso cadastrar uma conta Azure, e para mudar coisas como triggers era necessário pedir ao suporte. Para quem vem do mundo do GitHub ou de outros produtos SaaS, parecia uma tentativa de colocar uma casca nova sobre um modelo antigo
O caminho com Git LFS também tem algum suporte não oficial, mas se as coisas derem errado, você precisa se virar sozinho. A Epic não ajuda muito nisso. Especialmente se a meta for suporte oficial completo na engine, a concorrência nessa área seria muito bem-vinda
Escrevi um texto explicando por que merge de arquivos não é algo comum no mundo do desenvolvimento de jogos, para quem vem de desenvolvimento baseado em texto: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
Acabei de assumir uma equipe que usava Git, e eu sei que Git é o sistema de controle de versão favorito de todo mundo, mas para jogos ele chega perto de ser a pior escolha possível. Com Git, o tempo de revisão de arte era medido em horas; com Perforce, em segundos. Não é brincadeira
Ferramentas interessantes usadas pelo UE5, como Horde ou UBA, exigem Perforce
Mas o Perforce, apoiado na sua posição na indústria, não fez nada. É absurdamente caro, e não é como se operar a hospedagem não tivesse custo. Você precisa hospedar por conta própria e, em termos de desempenho, é até melhor fazer isso, mas depois da configuração inicial a manutenção é realmente dolorosa. Há sinais de que tentam fazer alguma coisa, mas sem direção clara, e quase tudo que fizeram vai contra o bom senso ou contra a própria base de usuários. O produto principal segue só mudando de nome, sem melhorias reais
É uma lição de como software proprietário pode virar uma prisão. Quero usar uma ferramenta de code review melhor que o Swarm, integrar SSO sem hooks estranhos em LUA que causam segfault na minha máquina, e rodar um backend de armazenamento distribuído em vez de depender de SSDs enormes e backups de journal. Até a licença fica amarrada ao endereço IP do servidor principal, então nem recuperação por backup funciona
É uma tecnologia esquecida, e quem opera essa empresa parece um zumbi
Não sei se a questão de permissões já foi resolvida, ou se já foi resolvido esse modelo híbrido de controle de versão distribuído/centralizado em que checkout por arquivo interage com o fluxo tradicional baseado em branches
Pelo FAQ, na prática isso não é um produto totalmente novo, e sim algo que só agora foi liberado como open source
“Lore, anteriormente chamado de Unreal Revision Control, é o sistema de controle de versão embutido no UEFN (Unreal Editor for Fortnite), e já vem sendo usado por criadores para gerenciar as versões de suas ilhas. As equipes internas da Epic também estão adotando-o gradualmente, e ele está sendo implementado como o repositório backend do pipeline de cook do UEFN, substituindo a camada intermediária de armazenamento existente para eliminar transferências duplicadas de arquivos e reduzir bastante o tempo entre publicar mudanças e elas se tornarem jogáveis.”
É surpreendente que seja em Rust, e não em Epic C++ ou Verse. Fico curioso com o motivo
O motivo de não ser Verse provavelmente é que esse trabalho não combinava com Verse. Isso continuaria valendo mesmo que Simon estivesse trabalhando em Verse. O motivo de não ser Haskell provavelmente é desempenho. DARCS também nunca se consolidou amplamente em parte por questões de desempenho
Além disso, isso acabaria se prendendo a todos os problemas e à lentidão do engine. A Epic cometeu esse erro no Epic Games Launcher. Na prática ele roda como uma instância do engine, o que é uma grande fonte de vários problemas
Comparando Verse e Rust, Verse é usado dentro da experiência do UEFN, mas ainda está longe de um estado de produção. Além disso, está essencialmente preso ao UEFN. Não é como se você pudesse baixar um compilador independente ou um REPL
Claro, exceto se estiverem abrindo porque decidiram parar o desenvolvimento, mas aqui não parece ser esse o caso
Full-surface API é um recurso que ninguém aqui mencionou. Fico me perguntando se isso é uma indireta ao fato de o Git deliberadamente não fornecer uma biblioteca linkável. Já vi este post antes: https://news.ycombinator.com/item?id=48470604
porcelainpara programas interagirem com ele. Não é algo linkável, mas ainda assim é uma APIA premissa é que o Git-LFS não é muito bom, então é preciso criar do zero, em Rust, um novo sistema de controle de versão de dados. Concordo em grande parte com essa premissa, mas já existem vários sistemas maduros de controle de versão de dados que usam internamente truques parecidos
Pachyderm(Go): https://github.com/pachyderm/pachyderm
XetHub(adquirido pelo HuggingFace): https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go): https://github.com/treeverse/lakeFS
Oxen(Rust): https://github.com/Oxen-AI/Oxen
Hoje em dia, graças à IA, talvez estejamos vivendo uma era em que qualquer um consegue fazer vibe coding de um sistema de controle de versão em Rust com endereçamento por conteúdo e deduplicação por chunks
Brincadeiras à parte, Lore parece realmente muito legal. O interessante é que domínios e setores diferentes têm problemas parecidos, mas não parece haver muita troca de ideias. Neste caso, tanto IA quanto jogos precisam de sistemas de armazenamento para versionamento de grandes arquivos binários. Parece haver muitas oportunidades para compartilhar ideias, e a falta atual dessa troca pode, por si só, criar uma oportunidade
Só essa diferença já pode exigir arquiteturas de armazenamento diferentes
Acho que parte do problema eram as concessões necessárias para manter o próprio Git e um armazenamento híbrido. Por isso, fico feliz que este sistema de controle de versão não use Git. O xethub também começou a lançar uma versão do produto que não usa Git, mas não tive chance de testar
Também usei o oxen e no começo ele não parecia ruim, mas logo encontrei problemas estranhos relacionados ao estado do repositório e não fui a fundo na depuração. Depois de passar por todos esses sistemas, ficou claro que nenhum deles é 100% satisfatório, e que Git para dados não é um problema trivial
Fico na dúvida se alguma empresa realmente vai implantar esse sistema, por exemplo, nos próximos 2 anos
Helix e Perforce fazem esse trabalho há décadas e, como isso faz parte central do negócio delas, dá para confiar. Você sabe que elas vão continuar dando manutenção ao produto por um bom tempo
Mas se a Epic abandonar esse projeto amanhã, nada acontece com o negócio dela. Na verdade, pode até ajudar o negócio ao liberar recursos de desenvolvimento
É parecido com a questão de por que alguém acreditaria que a Cloudflare vai continuar investindo no EmDash no longo prazo. A Cloudflare não se interessa por CMS. Oferecer a melhor experiência para leitores, autores e donos de sites não é o negócio deles. Isso é quase um projeto paralelo, pouco relacionado à atividade principal
Neste espaço, sempre houve até hoje um concorrente bem decente chamado PlasticSCM. A Unity o adquiriu alguns anos atrás, mas a Unity não foi uma boa gestora
Deveria ter feito como a Epic e liberado como open source, mas em vez disso escolheu colocá-lo sob responsabilidade de lucro e prejuízo. Fico curioso sobre quanto isso está contribuindo para as finanças da Unity hoje
Opiniões no Lobste.rs
Como foi otimizado para projetos de jogos/entretenimento que lidam com código e grandes assets binários ao mesmo tempo, talvez finalmente alguém tenha se cansado de décadas de monopólio do Perforce e resolveu fazer alguma coisa
Não parecia ser assim quando vi pela primeira vez, então fiquei curioso sobre por que agora recebeu a tag vibecoding
Por exemplo, explicações do tipo “Mercurial e Sapling são centrados em histórico de texto, enquanto Lore é voltado primeiro para binários” estão erradas. O Mercurial também é estruturado sobre um modelo de objetos binários, com funcionalidades de texto por cima
Como alguém que participou do desenvolvimento de Mercurial/Sapling, eu acredito que LLMs podem aumentar o rigor ao apontar alternativas que a equipe deixou passar, mas esse documento foi decepcionante. A decisão em si tem muitas vantagens, mas eu gostaria que tivesse sido um documento escrito com muito mais rigor
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
Será que este é o primeiro projeto em Rust que a Epic Games tornou público?
Vendo isto junto com as novidades sobre o sistema de controle de versão mais recente do Cursor, dá a impressão de que hoje em dia todo mundo quer criar um VCS
Fui só eu que pensei de cara “isso não deveria estar hospedado em cima do lore?”