Loading... # Manyana：基于 CRDT 的版本控制系统展望 # 一、新闻概述 ## 1. 标题 Manyana：Bram Cohen 发布基于 CRDT 的版本控制系统，合并永不失败 ## 2. 发布时间 2026 年 3 月 ## 3. 来源 Bram Cohen 官方博客 # 二、核心内容 ## 1. 事件摘要 ### A. 主要内容 BitTorrent 创始人 Bram Cohen 发布 Manyana 项目，这是一个基于 CRDT（Conflict-Free Replicated Data Types，无冲突复制数据类型）的版本控制系统演示，提出了版本控制的未来愿景。 ### B. 核心亮点 - 合并永不失败，CRDT 保证最终一致性 - 更智能的冲突标记，显示"发生了什么"和"谁做的" - 行顺序永久化，避免多分支合并问题 - 历史记录存储在数据结构中，而非依赖 DAG - Rebase 不需要销毁历史 - 约 470 行 Python 代码实现 ## 2. 关键信息 ### A. 涉及技术 - CRDT（Conflict-Free Replicated Data Types） - 版本控制 - 数据结构：Weave ### B. 项目状态 - 概念验证级别演示 - 公有领域代码 - 单文件操作 - 未实现：Cherry-picking、本地撤销 ### C. 核心特性 - 无阻塞合并 - 信息性冲突标记 - 永久行排序 - 历史感知 ## 3. 背景介绍 ### A. 作者背景 Bram Cohen 是 BitTorrent 的创始人，在分布式系统和版本控制领域有深厚经验。 ### B. 技术背景 传统版本控制系统（如 Git）使用 3-way merge，存在冲突处理困难、合并顺序敏感等问题。CRDT 是分布式系统中常用的数据结构，能保证最终一致性。 # 三、详细报道 ## 1. 主要内容 ### A. CRDT 基础原理 CRDT（无冲突复制数据类型）的核心特性： - 合并永不失败 - 最终一致性保证 - 合并结果与顺序无关 - 适用于多分支并行开发 ```mermaid graph TD A[分支 A 修改] --> M[CRDT 合并] B[分支 B 修改] --> M C[分支 C 修改] --> M M --> R[一致的结果状态] M -.从不失败.-> R ```  ### B. 冲突标记改进 传统 VCS 的冲突标记： ```python <<<<<<< left ======= def calculate(x): a = x * 2 logger.debug(f"a={a}") b = a + 1 return b >>>>>>> right ``` Manyana 的智能冲突标记： ```python <<<<<<< begin deleted left def calculate(x): a = x * 2 ======= begin added right logger.debug(f"a={a}") ======= begin deleted left b = a + 1 return b >>>>>>> end conflict ``` **改进点**： - 标记显示操作类型（删除/添加） - 标记显示操作来源（left/right） - 清晰展示冲突的结构 - 无需脑力重构发生了什么 ### C. 核心设计特性 #### 特性 1：行顺序永久化 当两个分支在同一点插入代码时，CRDT 选择一个顺序并保持永久。这解决了以下问题： - 冲突部分在不同分支上以不同顺序解决 - 多人独立工作时合并结果不一致 - 传统 VCS 在没有共同祖先时的合并困难 #### 特性 2：冲突不阻塞合并 - 合并总是产生结果 - 并发编辑"距离太近"时才会标记冲突 - 冲突仅用于审查，不阻止工作继续 - 算法追踪"每边做了什么"，而非仅显示两个结果 #### 特性 3：历史存储在结构中 状态是一个 Weave（编织结构）： - 包含文件中曾经存在的每一行 - 每行带有添加和删除的时间元数据 - 合并不需要查找共同祖先 - 不需要遍历 DAG ```mermaid graph LR A[状态 A] --> M[CRDT 合并] B[状态 B] --> M M --> R[结果状态] R --> W[Weave 结构<br/>包含完整历史] W -.无需.-> DAG[传统 DAG] ```  ### D. Rebase 的改进 传统 Rebase 的问题： - 创建虚构历史 - 销毁原始提交的真实上下文 - 激进 rebase 产生无共同祖先的拓扑 CRDT 系统的 Rebase： - 可以逐个重放提交到新基线 - **同时保留完整历史** - 仅需在 DAG 中添加"主要祖先"注解 **优势**： - 激进 rebase 不再破坏可追溯性 - 传统 3-way merge 在无共同祖先时失效 - CRDT 不在乎，历史在 Weave 中 ## 2. 技术细节 ### A. 架构设计 ```mermaid graph TB subgraph Manyana File[文件] --> CRDT[CRDT 引擎] CRDT --> Weave[Weave 结构] Weave --> History[历史记录] Weave --> State[当前状态] end CRDT -.合并永不失败.-> Weave Weave -.包含.-> History Weave -.派生.-> State ```  ### C. Weave 数据结构 Weave 是 Manyana 的核心数据结构： **特点**： - 单一结构包含所有历史行 - 每行带有完整生命周期元数据 - 支持高效的合并操作 - 无需重构历史 **优势**： - 合并复杂度与历史深度无关 - 支持任意分支拓扑 - 天然支持多路合并 ## 3. 数据与事实 ### A. 项目规模 - 代码量：约 470 行 Python - 许可证：公有领域（Public Domain） - 功能范围：单文件操作演示 ### B. 已实现功能 - CRDT 合并引擎 - 智能冲突标记 - Weave 数据结构 - 基本版本控制操作 ### C. 未实现功能 - Cherry-picking（拣选提交） - 本地撤销 - 多文件支持 - 完整 VCS 功能 ### D. 设计文档 完整设计文档包含在 README 中，涵盖了： - Cherry-picking 的设计思路 - 本地撤销的实现方案 - 完整 VCS 的构建路径 # 四、影响分析 ## 1. 行业影响 ### A. 技术趋势 - CRDT 在版本控制领域的应用探索 - 从"冲突解决"到"冲突避免"的范式转变 - 分布式版本控制的新方向 ### B. 竞争格局 - Git 统治地位面临新思路挑战 - 其他 CRDT VCS 项目：Dolt、Yjs 等 - 传统 VCS 可能借鉴部分概念 ### C. 生态影响 - 可能催生下一代版本控制工具 - 对协作工具有启发意义 - 推动 CRDT 技术更广泛应用 ## 2. 用户影响 ### A. 潜在收益 - 减少合并冲突处理时间 - 更清晰的冲突上下文 - 更自信的分支和合并操作 - 更好的多团队协作体验 ### B. 学习成本 - 新的冲突标记语法 - 不同的工作流程概念 - 需要理解 CRDT 基本原理 ### C. 迁移挑战 - 从 Git 迁移的成本 - 工具链生态成熟度 - 团队采用阻力 ## 3. 技术趋势 ### A. 技术方向 - 从 DAG-first 到 Structure-first - 从冲突解决到冲突避免 - 历史可追溯性优先 - 分布式协作优化 ### B. 未来发展 - 完整 VCS 实现的可能性 - 与现有工具的集成 - 性能优化和扩展性 - 企业级功能需求 # 五、各方反应 ## 1. 官方立场 Bram Cohen 强调 Manyana 是一个"演示"而非完整的版本控制系统，主要证明两点： - CRDT 版本控制可以处理困难的 UX 问题 - 提供了比现有工具更好的解决方案 ## 2. 技术意义 ### A. 突破点 - 解决了传统 VCS 的根本性问题 - 提供了清晰的冲突展示 - 保留了完整的历史记录 ### B. 局限性 - 当前仅为概念验证 - 缺少完整 VCS 的功能 - 需要更多工程实践 ## 3. 社区关注点 ### A. 积极评价 - CRDT 应用方向的创新 - 冲突标记的实际改进 - 开源和公有领域贡献 ### B. 技术讨论 - CRDT 在大规模代码库的性能 - 与 Git 生态的兼容性 - 实际生产环境的适用性 ### C. 未来展望 - 期待完整的 VCS 实现 - 希望更多工具集成 - 关注项目发展动态 # 六、相关链接 ## 1. 项目资源 - Manyana 代码仓库 - README 设计文档 ## 2. 技术背景 - CRDT 论文和研究 - Bram Cohen 的技术博客 ## 3. 相关项目 - Dolt（SQL 版本控制） - Yjs（CRDT 框架） - Automerge（CRDF 实现） *** ## 参考资料 1. [Manyana - Bram Cohen's Blog](https://bramcohen.com/p/manyana) 最后修改：2026 年 03 月 23 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏