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 採用了分塊儲存。檔案被拆解成具備索引查找功能的重複使用分塊，這減少了重複並透過僅更新檔案的修改部分來優化大型二進位資產的傳輸。

按需填充 (On-Demand Hydration)

Lore 透過按需填充支援稀疏工作區 (sparse workspaces)。使用者不需要預先下載整個儲存庫歷史紀錄或所有資產；相反地，系統僅在開發者或藝術家具體需要時才抓取檔案數據。

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