Epic Games Lore 版本控制系统

Epic Games 推出 Lore 用于大规模二进制资产版本控制

Epic Games 发布了 Lore，这是一个开源的版本控制系统 (VCS)，旨在解决结合了源代码与海量二进制资产的项目在扩展性方面面临的挑战。虽然 Git 针对文本文件进行了优化，但 Lore 是为游戏开发和娱乐行业的高数据需求而设计的，为 Perforce Helix Core 等专有系统提供了一个可扩展的替代方案。

Lore 根据 MIT 许可证发布，并以一组库、服务器和 CLI 的形式提供，同时还为 C/C++、C#、Rust、Go、Python 和 JavaScript 提供了 SDK。

技术架构：Merkle Trees 和分块存储

Lore 是一个中心化的、基于内容寻址的 VCS，它结合了 Merkle trees 和不可变修订链，以确保数据完整性和可扩展性。

基于内容寻址的存储与 Merkle Trees

Lore 通过 Merkle tree 中的内容哈希来引用仓库数据。这种架构使系统能够进行快速比较、验证数据完整性，并在不同的分支和历史记录中重复使用数据而无需重复存储。

不可变修订链

Lore 中的每一次修订都是经过加密签名的。修订的哈希值源自其状态，其中包含了其父修订的版本哈希以及所包含数据的哈希。这创建了一个防篡改的、不可变的真相链。

二进制资产的分块存储

为了高效处理大文件，Lore 采用了分块存储。文件被分解为具有索引查找功能的、可重复使用的块 (chunks)，这减少了重复并优化了大型二进制资产的传输，因为系统仅更新文件的修改部分。

按需填充 (On-Demand Hydration)

Lore 通过按需填充支持稀疏工作区。用户无需预先下载整个仓库历史记录或所有资产；相反，系统仅在开发者或艺术家需要特定文件数据时才进行获取。

Lore 与 Git 和 Perforce 的对比

Lore 的定位并非作为 Git 的通用替代品，而是作为游戏开发领域中 Perforce 的竞争对手。

应对 Git 的二进制限制

社区讨论指出，虽然 Git 对代码非常有效，但在处理纹理、3D 模型和音频文件时却显得力不从心。虽然存在 Git LFS (Large File Storage)，但它通常被认为不足以支持 AAA 级游戏开发中的大规模团队协作。

挑战 Perforce 的垄断地位

由于 Perforce Helix Core 能够处理大型项目并提供文件锁定功能，它目前是 Unreal Engine 开发的标准。Lore 旨在提供类似水平的性能和规模，但是在开源框架内实现的。行业资深人士指出，Lore 的成功可能取决于它与 Unreal Engine 的集成程度，因为 Epic 的内部使用情况通常决定了引擎所支持的最佳 VCS。

社区见解与批判性分析

虽然这一公告引起了关注，但技术用户针对 Lore 的当前状态和设计提出了几点看法：

  • 起源与来源： Lore 以前被称为 "Unreal Revision Control"，并作为 UEFN (Unreal Editor for Fortnite) 的后端存储。它是用 Rust 编写的，这与 Epic 传统的 C++ 或 Verse 的使用有所不同。
  • 工具链缺口： 一些用户注意到初始文档中缺乏可见的文件锁定工作流——这对于无法合并二进制资产的艺术家来说是一个关键功能。其他人指出，虽然核心代码是开源的，但桌面客户端目前仅以二进制文件形式提供。
  • API 可访问性： Lore 提供了一个 "full-surface API"，这被视为相对于 Git 架构的一个显著优势，因为 Git 缺乏一个易于集成到其他工具中的可链接库。
  • 与其它数据版本控制的对比： 一些开发者指出，Lore 的分块和内容寻址方法反映了现有的数据版本控制系统，如 Pachyderm、LakeFS 和 Oxen，这表明了 AI/ML 数据管理与游戏开发需求之间的趋同。

"Git 对代码等文本文件很好用，但在处理纹理、3D 模型、音频文件以及游戏开发者需要协作的其他非文本文件时表现很差... 该领域的 SOTA 是 Perforce... 一个专有系统。"

"Lore, 以前被称为 Unreal Revision Control, 是 UEFN (Unreal Editor for Fortnite) 的内置版本控制系统，创作者们一直在使用它来管理其岛屿的版本。"

Sources