Lore – Open source version control system designed for scalability

Lore – Open source version control system designed for scalability

来源：HackerNews

# Lore – 面向规模化设计的开源版本控制系统

## 背景与概述

版本控制系统（VCS）是现代软件工程的基石。从早期的 CVS、SVN 到统治开源世界的 Git，开发者们一直在寻找更高效的代码协作方式。然而，随着软件项目规模的指数级增长——代码库突破千万行、贡献者遍布全球、单体仓库（monorepo）成为大厂标配——Git 的架构局限性逐渐显现。微软 Windows 仓库、Google 的 Piper 等案例表明，现有工具在超大规模场景下面临着性能瓶颈、存储爆炸和协作复杂度陡增的挑战。

正是在这样的背景下，Lore 作为一个专为可扩展性设计的开源版本控制系统进入公众视野。该项目在 HackerNews 社区引发讨论，其定位并非要取代 Git 在普通项目中的地位，而是瞄准了那些让 Git 力不从心的极端场景：TB 级别的代码仓库、数万人的并行开发、跨地域的低延迟同步需求。Lore 的出现，代表了版本控制领域从"够用就好"向"规模化原生"演进的新思路。

值得注意的是，Lore 选择完全开源的路线，这与 Google 内部闭源的 Piper 形成鲜明对比。开源策略意味着 Lore 需要兼顾通用性与极致性能，同时构建开放的生态——这无疑增加了技术实现的难度，但也为其赢得了更广泛的应用潜力。

## 核心内容

### 1. 分层存储架构：告别全量克隆

Lore 最核心的设计哲学是**按需获取（lazy loading）**。传统 Git 要求开发者克隆完整仓库历史，这对于 Linux 内核（约 40GB）尚可接受，但对于包含十年历史的巨型 monorepo 则完全不现实。Lore 引入分层存储模型：

- **工作层（Working Layer）**：仅包含当前工作所需的文件快照
- **索引层（Index Layer）**：本地缓存的热点历史版本
- **远程层（Remote Layer）**：完整的版本历史存储于云端或分布式节点

这种设计让开发者在数秒内即可开始编码，而非等待数小时的数据传输。

### 2. 内容寻址的进化：从 SHA-1 到结构化哈希

Lore 保留了内容寻址的核心优势，但对其进行了现代化改造。不同于 Git 的扁平化对象存储，Lore 采用**结构化内容标识符（Structured Content ID）**：

// 概念性伪代码展示 Lore 的 CID 结构

struct ContentId {

hash: Blake3Hash, // 更快、更安全的哈希算法

chunk_boundary: Vec<u64>, // 支持增量同步的块边界标记

encoding_hint: EncodingType, // 压缩/编码元数据

}

Blake3 的使用带来显著性能提升——在相同硬件上，哈希计算速度可达 SHA-1 的 10 倍以上。而 chunk boundary 的嵌入则使二进制大文件（如游戏资源、ML 模型）的增量更新成为可能。

### 3. 操作转换与 CRDT：无锁协作的新尝试

Lore 在合并机制上大胆创新。传统 Git 的合并基于三路合并（three-way merge），在高度并行开发时冲突率激增。Lore 引入了**操作转换（Operational Transformation）**与**无冲突复制数据类型（CRDT）**的混合策略：

- 文本文件：基于字符级操作转换，实现实时协作编辑的语义级合并
- 结构化数据（JSON、Protobuf）：采用 CRDT 保证最终一致性，无需人工解决冲突
- 二进制文件：保留锁机制，但支持细粒度锁定（单文件而非全仓库）

### 4. 原生支持的大型文件管理

Git LFS 作为事后补丁，在 Lore 中被重新设计为**一等公民**。Lore 内置了类似 CDN 的内容分发网络集成，并支持**增量编码（delta encoding）**的智能选择：

Lore 的大文件操作示��

lore blob track "*.psd" --delta=bsdiff --threshold=1MB

lore sync --partial="assets/textures/hero/" # 仅同步指定路径

### 5. 可插拔的后端与多云策略

Lore 将存储后端抽象为接口，支持本地磁盘、S3 兼容对象存储、IPFS 甚至点对点网络。企业可构建**混合架构**：热数据存于本地 SSD，温数据在云端，冷数据归档至廉价存储。

## 技术分析

Lore 的架构设计体现了**系统研究前沿与工程实践的融合**。其技术栈的几个关键决策值得深入分析：

**存储层：从 Merkle DAG 到 Merkle Forest**

Git 的 Merkle DAG 是单棵树结构，所有提交最终指向同一个根。Lore 将其扩展为**Merkle Forest**——允许存在多棵独立的版本树，通过跨树引用（cross-tree reference）建立关联。这种设计天然支持：
- 仓库的浅层镜像（shallow mirror）无需完整历史
- 跨仓库代码复用（类似 Bazel 的 external 依赖但原生集成）
- 合规性要求的物理隔离（敏感代码存于独立树）

**传输协议：基于 QUIC 的自定义协议**

Lore 放弃 HTTP/2，基于 QUIC 构建传输层。QUIC 的连接迁移特性解决了移动开发者切换网络时的中断问题；其内置的流控则让 Lore 实现**优先级感知同步**——先传输 HEAD 提交，后台填充历史。

**查询引擎：Datalog 子集用于历史检索**

Lore 内置轻量级查询语言，支持复杂的历史检索：

// 查找 2024 年修改过 net/ 目录且未通过 CI 的提交

?commit :where {

?commit author ?author;

?commit time ?t;

?t > "2024-01-01";

?commit touches "net/";

?commit ci-status ?status;

?status != "passed"

}

这比 `git log --grep` 的组合命令更具表达力，且通过索引实现亚秒级响应。

## 实践建议

对于有意尝试 Lore 的开发者，建议采取**渐进式采纳**策略：

**阶段一：评估适用场景（1-2 周）**

并非所有项目都需要 Lore。若你的团队满足以下任一条件，可考虑迁移：
- 仓库体积超过 50GB 或文件数过百万
- 频繁处理 GB 级二进制资产（游戏、嵌入式、AI）
- 跨洲协作且网络条件恶劣
- 对 monorepo 有强烈需求但受限于 Git 性能

**阶段二：并行运行与验证（1 个月）**

使用 Lore 的 **Git 桥接模式**保持双向同步：

初始化桥接，保持与上游 Git 仓库同步

lore bridge init --upstream=https://github.com/org/legacy.git

lore bridge sync --bidirectional # 定时任务执行

此阶段重点验证：日常操作流畅度、CI/CD 集成兼容性、团队学习成本。

**阶段三：深度迁移（按需）**

完全迁移前，务必：
- 训练团队掌握 `lore` CLI 与核心概念（与 Git 的差异）
- 重写或适配 hooks、权限控制等企业级功能
- 制定回滚方案（Lore 支持导出为 Git 格式）

**特别提醒**：Lore 目前处于快速迭代期，生产环境使用建议锁定特定版本，并订阅安全更新通知。

## 总结

Lore 的出现并非要宣告 Git 的终结，而是为版本控制领域填补了一个长期被忽视的空白——**规模化原生设计**。它敢于打破"兼容 Git 就是政治正确"的惯性，从存储模型、传输协议到合并语义进行全面重构，这种技术勇气值得肯定。当然，生态建设是其最大挑战：Git 十五年的工具链积累（GitHub、GitLab、各类 IDE 集成）不可能一夜迁移。Lore 的成败将取决于能否在特定垂直领域（如游戏开发、芯片设计、企业级 monorepo）建立不可替代的优势，进而形成生态飞轮。对于开发者而言，即便暂不入局，关注其设计思想——分层存储、结构化哈希、CRDT 合并——也将反哺我们对现有工具的理解与优化。在软件工程持续规模化的趋势下，Lore 所代表的方向，很可能就是版本控制的下一个十年。