ハクソク

世界を動かす技術を、日本語で。

バージョン管理の未来

2026年3月23日原文(bramcohen.com)

概要

Manyana は、CRDTを用いた新しいバージョン管理のビジョンを提案するプロジェクト CRDTマージ により競合は情報提示のみで、実際のマージ失敗が発生しない 競合表示が従来よりも遥かに 分かりやすく、編集内容の構造を把握可能 履歴管理 やリベースも従来手法より優れた設計 Python製デモとして公開、設計思想をREADMEで解説

Manyana：CRDTベースの次世代バージョン管理の提案

  • Manyana は、バージョン管理の将来像を提示するプロジェクト
  • CRDT（Conflict-Free Replicated Data Types） を基盤とした設計
  • 従来のバージョン管理で課題だった マージ失敗や競合 を根本から解決
  • 競合は「発生しない」が、 編集内容の重なり は分かりやすく可視化
  • 競合箇所には「誰が」「何を」したかが 明確に表示 されるUI設計
  • 例：関数を片方が削除、もう片方が中身を編集した場合も 構造を保ったまま表示

CRDTの特長とバージョン管理への影響

  • CRDT は「最終的整合性」を保証し、どんな順序でマージしても結果は同じ
  • マージ時に 失敗やブロック が発生しない
  • 並行編集が近接した場合のみ 情報として競合 を提示
  • 競合解決は「どちらの編集内容か」を 明確に示す ため、従来より容易
  • 履歴は「 weave構造」で管理され、各行の追加・削除時期も記録
  • マージ時に 共通祖先の探索やDAGの走査 が不要

リベースと履歴管理の革新

  • 従来のrebase は履歴を「書き換え」てしまう問題
  • CRDT方式では、 プライマリアンセスター の注釈を加えるだけで、履歴を保ったまま「上書き」可能
  • 複雑なマージトポロジー でも破綻しない設計
  • 履歴は DAG再構成不要、weave構造に全て記録

Manyanaの現状と今後

  • Manyana は約470行のPythonデモで、個別ファイル単位の動作
  • cherry-pick や ローカルundo は未実装だが、READMEで実現方法を提案
  • CRDTベースVCS がUX課題を解決できることを 実証
  • コードはパブリックドメイン、設計思想はREADMEに全文記載

まとめ

  • CRDTによるバージョン管理 は、従来の課題（競合・履歴破壊・複雑なマージ）を根本解決
  • Manyana はその実現性と有用性を示す デモ兼設計書
  • 今後のバージョン管理システム設計に 大きな示唆

Hackerたちの意見

これは、ブラムのアイデアのいくつかを復活させて詳しく説明したものだね。Codevilleっていう、2000年代初頭のDVCSのカンブリア爆発の頃の試みから来てる。Codevilleもストレージとマージにウィーブを使っていて、これはSCCSから始まった概念なんだよね（それがTeamwareやBitKeeperに繋がっていった）。CodevilleはCRDTの導入の約10年前に作られたもので、少なくとも見た目にはこの2つの概念は自然に合ってるように思える。でも、ウィーブがgitやMercurialなどの経験則に基づくアプローチよりも明確に良いマージ結果を出すって主張するのはいつも難しかった。テストケースを作るために必要な編集履歴が、少なくとも私には理解しづらかったからね。ブラムがその問題を手放さず、新しいアイデアを試し続けているのが好きだな。

└

CRDTは「何か」ではないことに注意してね。CRDTの論文は、最終的に一貫性のあるレプリケーションメカニズムについて考えたり分析したりする方法を提供しているだけ。だからCRDTは「導入された」わけではなく、「レプリケーションを議論するCRDTの方法」があるだけ。CRDTの論文で説明されている具体的なメカニズムは、非常に古くて、数十年前から広く使われているものなんだ。つまり、最終的な一貫性を実装しているもの（Gitを含む）は「CRDTを使っている」ということになる。

└

2007年にブラムが、「君のCausal Treeアルゴリズムはweaveのバリアントだよ」って言ってくれたんだ。それは大体合ってる。ここ20年で、weave系のアルゴリズムはかなり増えたよ。2020年の記事では、彼らのファミリーポートレートを作ることにイントロを捧げたんだ。https://arxiv.org/abs/2002.09511 これ、別の記事にできたかもね。

三文目の重要な洞察は？ > ... バージョン管理のためのCRDT、これはずっと待たれていたけどまだ実現していない。Pijulは実際に存在していて、何百時間、場合によっては何千時間もの専門家の努力が注がれている。ブラムもその一人ではあるけど、投稿を読むとみんなが知ってることのように感じるね。

└

Pijulのことは聞いたことがなかったな。最初の検索で https://github.com/8l/pijul に行ったけど、11年間更新されてなかった。でも、実はそれは誤解で、公式リポジトリの https://nest.pijul.com/pijul/pijul は先月コミットがあったんだ。... もちろん、Pijulは開発にPijulを使っていて、GitやGitHubは使ってないからね！

└

変な趣味があるんだ。年に一回くらい、pijulマニュアルの理論ページ[0]を見に行って、TeXのフォーマットが直ってるか確認するんだよね。パッチを保存するためのより良い、より堅実なモデルが売りなら、プロジェクトに興味がある人が理解しやすいようにするのが普通だと思うんだけど。好奇心旺盛な読者に対して、マニュアルの第一印象を気にしないのは本当に変だよ。今、実験を始めてから約6年経ってる。約2年前（4年くらい前）に、Pijul Nestに行って[1]この問題を報告したこともあるんだ。ローカルでこの問題を直す方法の説明はもらったけど、なぜかその修正は公のバージョンには実装されてなかったんだよね。実験の進捗については、また1年後に報告するつもりだよ。[0] https://pijul.org/manual/theory.html [1] https://nest.pijul.com/pijul/manual/discussions/46

└

Pijul使ってる？たまに'pijul pull -a'をpijulソースツリーにやるんだけど、コンフリクトが出るんだ（自分のローカル作業はなし）。トラッキングアップデートプルの方法ってあるのかな？見当たらなかったから、リポジトリを捨てて再クローンしてる。そこでの進捗を追うのに何がうまくいってる？

失敗しないマージがあるのは良いことなのかな？ マージの失敗は、単に「同じ場所での2つの変更」だけじゃなくて、意味的な衝突を示すことが多いよね。そういうケースには気づいて手動で対処する必要があると思う。提案されたシステムがそれに対処しているとは思うけど、私のざっと読んだ限りではよくわからなかったな。

└

これ

└

重複があるマージはユーザーにフラグが立てられるって書いてあるけど、実際にはgitのデフォルトの違い以上のものではないと思う。衝突の警告を出して、両側を無条件に結合するだけのgitのバージョンも作れるんじゃないかな。

└

これについては触れられてるよね。実際に失敗しないわけじゃないけど…重要なのは、変更が互いに触れ合うときに対立としてフラグが立てられるべきだってこと。そうすることで、実際には失敗しないシステムの上に、情報を提供する対立の表示が得られるんだ。

└

同意するけど、Gitが時々苦しむ他の場面、たとえば同じdiffだけど親が違う二つのコミットを同等とみなすべきかどうか、これにこのアプローチが役立つか気になる。一般的には、そういうコミットは同じとはみなせないよね。あるブランチが別のファイルでフリップしたブール値をひっくり返すコミットを考えてみて。だけど、リベースされたブランチのように、同等とみなすべき一般的なケースもある。例えば、git branch -d BRANCHがリベースされたBRANCHがマージされたときに成功すべきだと決めるのにCRDTアプローチは役立つのかな？

Hacker Newsで議論の続きを見る