Manyana：CRDTに基づくバージョン管理の未来
BitTorrentプロトコルの創設者Bram Cohenが先週、Manyanaをリリースした。これはCRDT（Conflict-free Replicated Data Type）に基づいた全く新しいバージョン管理システムだ。このプロジェクトは核心的な問いに答えようとしている：バージョン管理の未来はどうあるべきか？
Gitの痛点：マージコンフリクト
Gitを使ったことがあれば、この苦痛を経験しているはずだ。二人が同じ関数を同時に修正し、マージ時に<<<<<<< HEADや>>>>>>> branchのマーカーが大量に出現。ほぼ同じコードを手動で比較し、原作者の意図を推測しながら、慎重にコンフリクトを解決しなければならない。
Cohenは典型的な例を挙げている：
- Aブランチが関数を削除
- Bブランチがその関数の途中にログ行を追加
Gitが提示するコンフリクトマーカーは不透明なコード片だ。何が起こったかを自分で想像しなければならない。一方、Manyanaのコンフリクトマーカーは明確に伝える：「左側が関数を削除、右側が関数内にログを追加」。
CRDTの核心的優位性
CRDTの重要な特性はマージが決して失敗しないことだ。どれだけ多くのブランチがあろうと、どんな順序でマージしようと、最終結果は常に一致する。これはバージョン管理にいくつかの根本的な変化をもたらす：
1. コンフリクトはマーカーであり、ブロックではない
従来のVCSでは、コンフリクトがマージ完了を阻止する。Manyanaでは、マージは常に成功して完了するが、システムが「問題があるかもしれない」コード領域をマークして人間のレビューに回す。さらに重要なのは、これらのマーカーが意味を持つことだ——各側が具体的に何の操作を行ったかがわかる。
2. 行の順序が永久に固定される
二つのブランチが同じ位置にコードを挿入すると、CRDTは順序を決定し永久に保持する。これにより、従来のrebase後に発生する奇妙な問題——同じコンフリクトコードが異なるブランチで異なる順序で保持される——を回避できる。
3. 履歴が構造の中に存在する
Manyanaは「weave（編み物）」構造を使用してファイルを保存する——これは存在したことのあるすべてのコード行を含む構造で、それらが追加・削除された時期のメタデータが付随している。つまり、マージに共通祖先を探す必要がない。二つの状態が入力され、一つの正しい状態が出力される。
Rebaseは履歴を破壊する必要がない
従来のrebaseの問題は、虚偽の履歴を作り出すことだ。あなたのコミットは、実際にはそうでなくても、最新のmainブランチ上で行われたように見える。
Manyanaは、完全な履歴を保持しながらrebaseの効果を実現できる。DAGに「主要祖先」の注釈を追加するだけで、線形履歴の外見を得られる一方で、実際に発生したすべてのブランチマージの記録を保持できる。
これは「きれいなコミット履歴」を貴重視するチームにとって特に魅力的だ——見栄えの良いgit logのために真実の履歴を犠牲にする必要がなくなる。
現実の検証
Manyanaはまだ初期段階にある。CRDTによるバージョン管理の概念自体は新しくないが、これまでの失敗プロジェクトはユーザーエクスペリエンスで躓いてきた。Cohenの洞察は正しい：CRDTマージは常に成功する、問題は意味のある形で並行修正を提示する方法だ。
Gitは15年間、バージョン管理を支配してきた。そのデータモデルはエレガントだが、UX層には確かに多くの歴史的な重荷がある。Manyanaが成功するかどうかは、CRDTの理論的優位性を維持しながら、Gitより直感的なワークフローを提供できるかにかかっている。
少なくとも、注目に値する実験だ。