DVCSおよびDAG

Eric Sinkによる翻訳-DVCSおよびDAG（ パート1およびパート2 ）。

ご注意 翻訳者：この記事では、元の英語の略語DVCSおよびDAGを使用して、分散バージョン管理システム（DVCS）および有向非巡回グラフ（有向非巡回グラフ-DAG）を参照します。

パート1

人々には2つのカテゴリがあります。

1. すべてを2つのカテゴリに分割しようとしている人。
2. しない人。

私は最初の一人です。 :-)

バージョン管理システムには2つのカテゴリがあります。

1. 歴史がラインであるもの。
2. 履歴が方向性非循環グラフ（DAG）であるもの。

従来のツール（SubversionやVaultなど）は、Linesのような歴史に引き寄せられます。 DVCS（GitやMercurialなど）では、履歴はDAGです。 2つのモデルの違いは非常に興味深いです。

線形モデルがテストされ、機能しています。 履歴は、次々と続く一連のバージョンです。


新しいバージョンを作成するには、次のものが必要です。

1. 最新バージョンを入手してください。
2. 変更を加えます。
3. 行われた変更をコミットします。

人々はそのシンプルさから線形モデルを愛しています。 どのバージョンが最新であるかという質問に対する正確な答えを提供します。

しかし、線形モデルには1つの大きな問題があります。最新バージョンに基づいている場合のみ、新しいバージョンを作成できます。 そして、しばしば次のことが起こります。

1. リポジトリから最新バージョンを取得します。 受け取った時点では、バージョン3でした。
2. そこで変更を加えます。
3. これを行っている間に、誰かがバージョン4を作成しています。
4. 変更をコミットするとき、現在のバージョンに基づいていないため、これを行うことはできません。 変更の「ベース」はバージョン3で、これは作業を開始した時点で関連がありました。

ストーリーの線形モデルでは、図に示すようにバージョン5を作成できません。 代わりに、3番目から4番目のバージョンに加えられた変更を強制的に取得し、それらを自分のバージョンに「マージ」します。

明らかな質問は、3番目に基づいて5番目のバージョンの修正を許可するとどうなりますか？ 私たちの物語はラインではなくなります。 そして、DAGに変わります。

なぜこれを行う必要があるのですか？

DAGモデルの主な利点は、開発者が作業の結果を修正しようとしているときに開発者を中断させないことです。 この点に関して、DAGはおそらく、同時開発を実践しているチームで実際に起こっていることをより正確に反映したものです（ ここでは、「同時開発」という用語の非常に正確ではない翻訳が使用されます。同じコードで頻繁に競合する-約 。 バージョン5は3rdによって設立されたので、なぜこの事実を反映しないのでしょうか？

確かに、これを行わない理由があることがわかります。 この列では、どのバージョンが「最新」であるかはわかりません。 そして、これは多くの問題につながります：

• リリースリリースのためにバージョン4および5での変更が必要だとします。 現時点ではこれを取得できません。 システムには、両方の変更セットを含むバージョンはありません。
• ビルドシステムは、最新バージョンを自動的にビルドするように構成されています。 この状況で彼女は何をすべきでしょうか？
• 4番目と5番目の両方のバージョンを収集した場合でも、テストのためにQAに送信する必要があるのはどれですか？
• 開発者が自分のツリーを最新バージョンに更新したい場合、どちらを優先すべきですか？
• 開発者がいくつかの変更を行う場合、どのバージョンを基礎として使用する必要がありますか？
• プロジェクトマネージャーは、どのタスクが完了し、どれだけの作業が残っているかを知りたいと考えています。 「完了」に対する彼の理解は、「最後」の概念と非常に密接に関連しています。 どのバージョンが最新かわからない場合、ガントチャートを更新しようとして脳が溶けます。

はい、これは悲しい写真です。 私たちが知っているように、世界は文字通り私たちの目の前で崩壊しています。

継続的な集団ヒステリーの状態で犬と猫の共存を避けるために、歴史のDAGモデルを使用するツールは、混乱を解決するのに役立つすべてのことを行っています。 答えは線形モデルと同じです。 マージが必要です。 ただし、変更をコミットする前に開発者にマージを要求する代わりに、後でこのマージを実行できます。



バージョン4および5で行われたすべての変更を含むバージョンを作成する必要があります。このバージョンが修正されると、両方の「親」を指す矢印が含まれます。

注文が復元されました。 もう一度、どのバージョンが「最後」であるかがわかります。 マネージャーを再起動する必要があることを誰かが覚えている場合、彼はこのグラフがほとんど線のように見えることにすぐに気付くでしょう。 そして、バージョン3と6の間で不可解で分かりにくいことが起こったことを除いて、 これが Lineです。 しかし、マネージャーにとって最善のことは、これについてあまり心配しないことです。

このマネージャーが知らないことは、この特定の危機は些細なことだということです。 彼は古いパラダイムは完全に破壊されたと考えていますが、いつかオフィスに来てこれを見つけるでしょう：


＆@＃！

そして今何？

線形モデル内に住んでいる場合、このグラフは絶対的な悪夢です。 彼には4つのターミナルノードがあります。 上記のマネージャーを含め、どのバージョンが最新であるかを理解する必要があるすべてのものは失敗する運命にあります。

線形モデルは、このような瞬間に非常に魅力的に見えます。 そして、これは、99.44％の開発者が線形履歴モデルに基づいたSCMツールを使用しているという事実の正当な理由です（そう、これらの統計を発明しました）。

しかし、この明らかな混乱にもかかわらず、DAGモデルの主な利点を思い出さなければなりません。それは、プログラマーの仕事における実際の仕事のコースをより正確に記述するものです。 線形モデルのように、開発者が望みどおりに曲げることを強制しません。 開発者が何かを修正したい場合、それを行います。 そして、DAGは実際に起こったことを正確に記録します。

多くのチームは常に線形モデルを好みます。 そして、それは何も悪いことではありません。 このアプローチにより、生活が楽になります。

ただし、他の一部のチームにとっては、DAGモデルは非常に便利です。 また、一部のチームにとっては、一般的に「負荷をかける」ことができます。 他の理由でDVCSを使用する必要があるからです。 DVCSツールは選択肢がないため、DAGモデルを使用します。 中央サーバーとの永続的な接続を想定できない場合、他の方法はなく、開発者にすべての作業を線形モデルに適合させることはできません。

したがって、DAGを管理する方法を見つける必要があります。 そして、私たちは何をしますか？

1つのオプションは、各操作を再構築することです。 医師に「最新バージョンを判断する必要が生じたとき、これは本当の拷問です」と伝えると、医師は「これをやめないでください」と言うでしょう。 代わりに、使用するノードを常に正確に指定します。

• ビルドシステムは最後のノードを組み立てません。 代わりに、彼女は私たちが見せたものを正確に収集します。 または、彼女はすべてのノードを収集します。
• QAは、誰かがテストする必要があると考えるビルドをテストします。
• 開発者は、ツリーを「最後」に更新しません。 代わりに、グラフを見て、ノードを選択して更新します。

このアプローチが適切であると言っているのではありません。 私は彼が理論的に正しいことに注意したいだけです。 使用する正確なノードを指定できる限り、これらの各操作を実行できます。

しかし、ノードをどのように指定しますか？ このアプローチを問題にしている状況の1つは、これらのノードがしばしば複雑な名前を持っていることです。 たとえば、Gitでは、ホスト名はe69de29bb2d1d6434b8b29ae775ad8c2e48c5391のようになります。 開発者は、この命名方法はあまり直感的ではないと感じています。

すべてのDVCSツールはDAGを使用します。 そして、それらはすべて、「複数端末ノードの危機」を防ぐため、またはチームがそれに対処するのを助けるために、多くの異なることを行います。 しかし、彼らは皆、独自の方法でそれを少し行います。

幸いなことに、これにより、すべてを2つのグループに分ける便利な機会が得られます。

1. 私が好きな方法でこの問題を解決する人。
2. そして、私が好きではない方法でこの問題を解決する人たち。

パート2

この記事の最初の部分では、2種類の注目に値するレビューを受け取りました（ 元の記事の著者であるEric Sinkは、1週間の時間差で2部に分けて公開しました。 ：

1. 数人の人々が私に恐怖、不確実性、疑念を広めたと非難しました（ 原作では、著者は共通のFUDスラングの略語-Fear Uncertainly and Doubtを使用しています。彼はDAGモデルの問題に言及し、文字通り、DAGモデルが癌の治療法であり、地球温暖化を止め、中東に平和と静けさをもたらすことができると述べることから一歩離れました。
2. 一部の人々は、このようなクールなチャートをどのように描いたのかと尋ねました。

第二部を始める前に、これらのレビューの両方に簡単に答えさせてください。

DVCSの防衛における私の答え

はい、私の会社（ SourceGear 、-およそPer。 ） は 、履歴の線形モデルに基づいてバージョン管理システム（Vault）を開発しています。 したがって、DVCSは、ある程度、私の製品の直接の競合相手です。

私は多くの規則に違反していることをよく知っています。

• 私のようなビジネスコミュニティの代表者は、競合他社について良いことを言うべきではありません。
• 私たちの仕事は、変化を恐れ、この恐れを他の人に広めることです。
• 私たちは、どの選択肢にも副作用があることを知らないふりをして、どのような状況でも選択肢が優れていると主張するはずです。

私の母は私がいつも規則をうまく守っていないことを簡単に確認します:-)

このトピックが面白いと思うだけです。 私はバージョン管理業界で10年以上働いています。 このテーマに関する本を書いています。 これが私がやっていることです。 ここに私が興味を持っていることがあります。

実際に。

しかし、資本家の反逆者としての私以上のものがあります。

Gitファンの皆さん、少し冷やす必要があります。

真剣に、Gitの熱心な擁護者は、この世界を居住不可能にします。 Gitは本当に素晴らしいことですが、それは例外なくすべての状況で正しい選択ではないということです。

彼らの弁護では、この問題でリンゴがリンゴの木の近くに落ちたことを認めなければなりません。 人々がDVCSに興味を持つようになると、最初に出くわすものの1つは、Gitに関する2007 Linus Torvaldsプレゼンテーションのビデオです 。 そしてそこには、これも理解していないようです。

みんな、Subversionはおそらく現時点で世界で最も人気のあるバージョン管理ツールです。 現在、バージョン管理システムを使用するほとんどすべての人が、履歴の線形モデルに基づいたものを使用しています。 そして、彼らはこれらのツールを効果的かつ生産的に使用しています。 誰かがこのモデルの適合性を認めることを拒否するとき、彼らは愚かに見える。

トーバルズのビデオは大きなダメージを与えました。 この立場は、バージョン管理の世界の新機能に興味がある人にとっては大きな失望です。

したがって、私の親愛なるGitのファン、あなたが人々にDVCSの使用を警告し、彼らが現在のアプローチを変えないことを確実にしたいなら、あなたは同じやり方で続けることができ、あなたは素晴らしいことをしている。

しかし、Gitや同様のツールの利点を世界に見てもらいたい場合は、登場前に人々が生産的に仕事をしたことを理解してください。

これらのクールなチャートに関する私の答え

これらの写真は、SourceGearのイラストレーターJohn Woolleyによって描かれました。JohnWoolleyは、漫画本Evil Mastermindのイラストもすべて作成しました。 ジョンは、ソースコード管理に関する今後の本の設計作業とイラストのすべてを行っています。

それにもかかわらず、ジョンの写真は私の「千の言葉」よりもはるかに称賛を受けたので、私は怒って、記事の第2部に彼のイラストを含めることを拒否しました。 :-)

グラフについてもう少し話しましょう

最初の部分で述べたように、DAGがコントロールなしで成長することを許可された場合、すべてが真の混乱に変わる可能性があります。 DAGは簡単に作成できます。 線は使いやすいです。 DAGモデルを最大限に使用してその利点を最大限に活用し始めるとすぐに、次に起こることはラインを戻すことです。

そのため、どのDVCSにも、DAGの成長を管理しやすくするために使用できる機会があります。 これらの機能は、開発者が変更をコミットするのを防ぎ、新しいブランチポイントを作成するたびに生じる複雑さに対する責任を回避するために考案されました。

言い換えれば、各DVCSには、開発者がグラフの断片を取得して線として扱うことができる機能が含まれています。

Git

Gitは、名前付きブランチをサポートすることでDAGの成長を制御します。 「親」がエンドノード（「リーフ」）でない場合、変更をコミットする機会が奪われます。

したがって、Git checkoutコマンドを使用してリポジトリの作業コピーを非ターミナルノードに更新すると、Gitは丁寧に対応してくれます。

  eric $ git checkout 9542b
注：ローカルブランチではない「9542b」に移動
このチェックアウトから新しいブランチを作成する場合は、作成できます
 （現在または後で）checkoutコマンドで-bを再度使用します。 例：
   git checkout -b
 HEADは現在9542b5fです...初期 

常にエンドノードのみに基づく変更をコミットする場合、ストーリーはラインに非常に似たままになります。

マーキュリアル

歴史的に、Mercurialはリポジトリごとに1つのブランチのみをサポートすると説明されてきました。 Gitとの比較は、多くの場合、同じリポジトリ内での分岐サポートの欠如という明らかな欠陥に焦点を当てました（ ここで、翻訳は元のテキストに対応していません。これは、著者が記事へのコメントに約

Mercurialでこの領域にいくつかの機能が追加されたと聞いたので、過去形で話しています。

ここでMercurialに言及したのは、彼のファンを脇に置いてしまわないためです。 このシステムでの幅広い経験のある立場から話すことはできません。

しかしそれにもかかわらず、私は視点の確認としてMercurialに言及することが可能であると考えています。初期（少なくとも）バージョンでは、Mercurialはグラフの成長を制御し、分岐を防ぎました。 さらに、これは非常に使いやすいツールとしてのMercurialの一般的な認識に貢献しました。

バザール

このツールは、私が最もよく使用したDVCSですが、それでも私はまだ自分をエキスパートと見なすことはできません。 私の経験では、私はBazaarをDAGの成長を制御するために懸命に働くシステムとして特徴づけるでしょう。

ローカルリポジトリから中央サーバーに変更を送信しようとするたびに、Bazaarではエンドノードからの他の変更とマージする必要があります。 線形モデルを持つシステムとまったく同じです。

しかし、おそらく素晴らしいことですが、Bazaarは私に本当のDVCSのような中央サーバーを使わない機会を与えてくれます。 ただし、このモードでは、同じ重要な制限が適用されます。リポジトリの最終ノードに基づいていない変更はコミットできません。

Bazaarを使用するとき、線形モデルを備えたツールを使用しているように感じます。

私の好み

この点で、この問題を解決するためのGitのアプローチは私に最も近いです。

Bazaarは、DAG分岐がリポジトリの個別のインスタンスで発生する場合にのみ許可され、あるリポジトリから別のリポジトリに変更を転送する前に解決する必要があると信じているようです。

Gitがリポジトリのローカルコピーをgit checkoutファイル名で切り替える機能が気に入っています。 私は、DAGの絶え間ない思考に慣れていない人にとって、この可能性は理解できないように見えることを理解しています。 しかし、私は彼女が好きです。

私はまだSubversionやVaultなどの線形モデルツールが好きであることに注意してください。 DAGモデルを備えたツールは、同様の方法で動作する必要があると言いたいだけです。

化石

最近私を最も興味を引いたDVCSはFossilです。 SQLiteの作成者であるD. Richard Hippによって書かれました。

Fossilには多くの興味深い機能があります。 最も重要なのは、バグ追跡の組み込みサポートです。 これは、他のすべてのDVCSが劣っている領域です。 分散バージョン管理を提供しますが、開発者がバグトラッカーの情報を更新するときが来ると、世界は再び中央集権化されます。

いずれにせよ、Fossilを詳しく調べ始めたばかりですが、分岐の問題がそのWebサイトでどのように説明されているかが気に入っています。

ツリーに複数の端末ノードがあることは通常望ましくないため、図2のように分岐は通常完全に回避されます。 1、または図1のようにすぐに削除されます。 3（ 化石のウェブサイトではなく、この記事の数字を意味します-約Per。 ）。 ただし、複数のエンドノードが必要な場合があります。 たとえば、プロジェクトには、製品の開発バージョンの最新バージョンを表す1つのエンドノードと、最後の「安定した」（テスト済み）バージョンの2番目のノードを含めることができます。 複数のターミナルノードが適切な場合、分岐ではなく分岐と呼びます。 （ 英語の用語branchとforkの違いを感じることは重要です。著者は、用語branch（branch）の肯定的な意味と、ある程度、fork（fork）の否定的な性質を強調することを望んでいます 。

素晴らしい。 その結果、Fossilはこの点でGitと同様に機能するという印象を受けました。 DAGが分岐すると、複雑さが増します。