Lore – Sistema de controle de versão de código aberto projetado para escalabilidade

Uso pretendido e posicionamento

• Visto principalmente como um substituto do Perforce para desenvolvimento de jogos e outros fluxos de trabalho pesados em ativos, não como um substituto geral do Git.
• Usuários-alvo: equipes que misturam programadores e artistas, com repositórios medidos em centenas de GB–TB e dominados por ativos binários (texturas, modelos, áudio, níveis).

Por que Git (e Git LFS) têm dificuldades aqui

• Git é excelente para texto/código, mas ruim para binários grandes:
  • Repositórios e clones incham rapidamente; o histórico fica enorme e lento.
  • Git LFS adiciona bloqueio e indireção, mas é descrito como frágil, confuso e difícil de configurar em escala; são mencionados problemas frequentes de autenticação e corrupção.
  • Não há permissões granulares; o acesso é por repositório inteiro, a menos que você divida os repositórios ou use submódulos de forma complicada.
  • Sparse checkout e clones parciais existem, mas são cheios de arestas e não são amigáveis para artistas.
• O CLI e a saída do Git são amplamente criticados por serem confusos e excessivamente verbosos, especialmente para não engenheiros.

Como o Lore diz ajudar

• Projetado em torno de ativos binários grandes:
  • Armazenamento em chunks para deduplicação e transferências parciais mais rápidas.
  • Hidração sob demanda / cópias de trabalho esparsas, para que os usuários baixem apenas os ativos de que precisam.
  • Bloqueio nativo de arquivos para impedir edições simultâneas de ativos que não podem ser mesclados.
  • Permissões por diretório/ativo e isolamento multi-tenant.
• CLI no estilo Git para desenvolvedores; um cliente desktop com GUI para artistas é prometido (binário disponível agora, código-fonte será aberto mais tarde).
• Superfície completa de API pretendida, ao contrário da postura do Git de “não oferecer biblioteca”.

Centralização, escala e arquitetura

• Lore é explicitamente centralizado (mais parecido com Perforce do que com Git); peer-to-peer não é um objetivo.
• Projetado para sustentar coisas como pipelines do Unreal Engine/UEFN; descrito como já usado internamente para conteúdo do Fortnite.
• Implantações multi-região atualmente dependem de serviços da AWS como DynamoDB, levantando preocupações sobre acoplamento à nuvem.

Ferramentas, UX e preocupações com adoção

• Muitos ressaltam que UE e Perforce funcionam bem juntos hoje; a inércia de migração é alta porque artistas não gostam de aprender novas ferramentas.
• O sucesso do Lore é visto como dependente de integração profunda com Unreal, Unity, ferramentas DCC (Maya, Blender etc.) e uma GUI polida.
• Alguns perguntam se o Lore é bom o suficiente em texto/código puro para substituir o Git em toda a organização; outros observam o lock-in do ecossistema em torno das ferramentas do Git.

Confiança na Epic e maturidade do projeto

• Ceticismo em vincular infraestrutura central à Epic:
  • Decisões passadas (por exemplo, abandono do suporte a Linux/macOS para jogos, controvérsias da Epic Store) são citadas como problemas de confiança.
  • Medo de que o Lore possa ser abandonado ou transformado em um upsell de “open core”, apesar da licença MIT.
• Documentação e páginas de design são amplamente percebidas como geradas por LLM, verbosas e difíceis de ler; isso mina a confiança no rigor, embora o sistema subjacente possa ser sólido.
• Alguns observam que ele ainda não está “pronto para produção” segundo o próprio FAQ; muitos vão esperar por mais relatos do mundo real.

Aplicabilidade mais ampla e comparações

• Outros domínios (datasets de ML/AI, CAD, modelagem 3D, fotografia, PDM/PLM) veem potencial em um VCS voltado primeiro a binários.
• Comparado a ferramentas de dados/BLOB existentes (git-annex, DVC, lakeFS, Pachyderm, Oxen, XetHub) e outros VCSs (Mercurial, SVN, PlasticSCM, Diversion, jj, Pijul); o consenso é que “Git para dados/gamedev” continua sendo um problema difícil e não resolvido, então mais experimentação é bem-vinda.