Lore – 面向可扩展性的开源版本控制系统

原文 ↗ Hacker News 讨论 ↗

预期用途与定位

  • 主要被视为面向游戏开发和其他资产密集型工作流的 Perforce 替代品，而不是通用的 Git 替代品。
  • 目标用户：将程序员和美术人员混合在一起的团队，仓库规模以数百 GB–TB 计，且主要由二进制资产组成（纹理、模型、音频、关卡）。

为什么 Git（以及 Git LFS）在这里吃力

  • Git 非常适合文本/代码，但对大型二进制文件表现很差：
    • 仓库和克隆会迅速膨胀；历史记录变得巨大且缓慢。
    • Git LFS 增加了锁定和间接层，但被描述为脆弱、令人困惑，并且难以在大规模场景下配置；文中提到频繁的认证和损坏问题。
    • 没有细粒度权限；除非拆分仓库或使用别扭的子模块，否则访问权限是按整个仓库控制的。
    • 稀疏检出和部分克隆虽然存在，但操作棘手，对美术人员不友好。
  • Git 的 CLI 和输出也被广泛批评为令人困惑且过于啰嗦，尤其对非工程师而言。

Lore 声称如何提供帮助

  • 围绕大型二进制资产设计：
    • 分块存储，用于去重和更快的部分传输。
    • 按需 hydration / 稀疏工作副本，让用户只拉取所需资产。
    • 原生文件锁定，防止对不可合并资产的并发编辑。
    • 按目录/资产的权限控制和多租户隔离。
  • 为开发者提供类似 Git 的 CLI；同时承诺提供面向美术人员的 GUI 桌面客户端（目前已有二进制版，源码之后开放）。
  • 计划提供完整 API 接口，这一点不同于 Git “没有库” 的立场。

中心化、规模与架构

  • Lore 明确是中心化的（更像 Perforce 而非 Git）；点对点不是目标。
  • 设计目标是支撑 Unreal Engine/UEFN 这类流水线；据说已在内部用于 Fortnite 内容。
  • 当前的多区域部署依赖 DynamoDB 等 AWS 服务，这引发了对云绑定的担忧。

工具、UX 与采用方面的担忧

  • 许多人强调，UE 和 Perforce 目前配合得很好；迁移惯性很高，因为美术人员不喜欢学习新工具。
  • Lore 的成功被认为取决于与 Unreal、Unity、DCC 工具（Maya、Blender 等）的深度集成，以及一个打磨良好的 GUI。
  • 有人质疑 Lore 在纯文本/代码方面是否足够好，能否在整个组织范围内替代 Git；也有人指出 Git 工具生态存在锁定效应。

对 Epic 的信任与项目成熟度

  • 对于将核心基础设施绑定到 Epic，很多人持怀疑态度：
    • 过去的决定（例如放弃游戏的 Linux/macOS 支持、Epic Store 争议）被拿来作为信任问题的例子。
    • 担心 Lore 可能会被弃置，或尽管采用 MIT 许可，最终变成“open core”式的升级销售。
  • 文档和设计页面被普遍认为像是 LLM 生成的，冗长且难以阅读；这削弱了人们对其严谨性的信心，即便底层系统可能是扎实的。
  • 也有人指出，按照其 FAQ，它目前还不是“生产可用”的；很多人会等待更多真实世界的反馈。

更广泛的适用性与比较

  • 其他领域（机器学习/AI 数据集、CAD、3D 建模、摄影、PDM/PLM）也看到了二进制优先 VCS 的潜力。
  • 与现有的数据/BLOB 工具（git-annex、DVC、lakeFS、Pachyderm、Oxen、XetHub）以及其他 VCS（Mercurial、SVN、PlasticSCM、Diversion、jj、Pijul）相比；共识是“面向数据/游戏开发的 Git”仍然是一个困难且尚未解决的问题，因此欢迎更多试验。