集中バージョン管理システムと分散バージョン管理システム (DVCS)を使用する利点と欠点は何ですか? DVCS で何か問題に遭遇したことがありますか? また、これらの問題をどのように防止しましたか? ディスカッション ツールにとらわれず、炎上を最小限に抑えます。
どの DVCS ツールが利用できるのか知りたい方のために、最もよく知られているフリー/オープン ソースの DVCS のリストを以下に示します。
分散型バージョン管理システム (DVCS) は、集中型 VCS とは異なる問題を解決します。それらを比較することは、ハンマーとドライバーを比較するようなものです。
集中化された VCSシステムは、祝福された 1 つの真のソースがあり、したがって良いという意図で設計されています。すべての開発者がそのソースから作業 (チェックアウト) し、変更を追加 (コミット) すると、同様に Blessed になります。CVS、Subversion、ClearCase、Perforce、VisualSourceSafe、およびその他すべての CVCS の唯一の実質的な違いは、各製品が提供するワークフロー、パフォーマンス、および統合にあります。
分散型 VCSシステムは、1 つのリポジトリが他のリポジトリと同等であること、および 1 つのリポジトリから別のリポジトリへのマージが単なる別の通信形式であることを意図して設計されています。どのリポジトリが信頼されるべきかに関するセマンティック値は、ソフトウェア自体ではなく、プロセスによって外部から課せられます。
どちらのタイプを使用するかの実際の選択は組織的なものです。プロジェクトまたは組織が集中管理を必要とする場合、DVCS はスターターではありません。中央リポジトリへの安全なブロードバンド接続がなく、開発者が全国/世界中で作業することが期待されている場合、DVCS はおそらくあなたの救いです。両方が必要な場合は、fsck を実行します。
分散システムでは正規のコピーが許可されていないと考えている人は、分散システムが正規のコピーを持つ場所がたくさんあることに注意してください。完璧な例は、おそらく Linus のカーネル ツリーです。確かに多くの人が自分の木を持っていますが、ほとんどの人がライナスの木に向かって流れています。
そうは言っても、私は分散 SCM はさまざまなことを行う多くの開発者にとってのみ有用であると考えていましたが、最近、集中型リポジトリでできることは分散型リポジトリよりも優れていると判断しました。
たとえば、あなたが個人的なプロジェクトに取り組んでいるソロ開発者であるとします。一元化されたリポジトリは当然の選択かもしれませんが、このシナリオを検討してください。あなたはネットワーク アクセスから離れており (飛行機、公園など)、プロジェクトに取り掛かりたいと考えています。ローカル コピーがあるので問題なく作業できますが、ある機能を終了して別の機能に移りたい、または修正すべきバグを見つけたなどの理由で、本当にコミットしたい場合があります。ポイントは、集中リポジトリでは、すべての変更をまとめて非論理的な変更セットにコミットするか、後で手動で分割することになります。
分散レポを使用すると、通常どおりビジネスを開始し、コミットして先に進み、再びネットにアクセスできるようになったら、「1 つの真のレポ」にプッシュしても何も変わりません。
分散リポジトリのもう 1 つの利点は言うまでもありません。完全な履歴をいつでも利用できます。ネットから離れているときにリビジョン ログを確認する必要がありますか? バグがどのように導入されたかを確認するには、ソースに注釈を付ける必要がありますか? 分散リポジトリですべて可能です。
分散型と集中型が所有権や信頼できるコピーなどに関するものだとは思わないでください。Reality is distributed は、SCM の進化における次のステップです。
W. Craig Traderは、DVCS と CVCS について次のように述べています。
両方が必要な場合は、fsck を実行します。
両方を使用している場合、 fsckされているとは言えません。実際には、DVCS ツールを使用する開発者は通常、中央の場所 (通常はリリース リポジトリのリリース ブランチ) に対して変更をマージ (またはプル リクエストを送信) しようとします。DVCS を使用する開発者にはいくつかの皮肉がありますが、最終的に集中型のワークフローに固執すると、分散型のアプローチが本当に集中型よりも優れているかどうか疑問に思うかもしれません。
CVCS よりも DVCS にはいくつかの利点があります。
一意に認識可能なコミットの概念により、ピア間でパッチを簡単に送信できます。つまり、パッチをコミットとして作成し、それを必要とする他の開発者と共有します。後で全員が一緒にマージしたい場合、その特定のコミットが認識され、ブランチ間で比較できるため、マージの競合が発生する可能性が低くなります。開発者は、使用するバージョン管理ツールに関係なく、USB スティックまたは電子メールで互いにパッチを送信する傾向があります。残念ながら CVCS の場合、バージョン管理はコミットを別々のものとして登録し、変更が同じであることを認識できず、マージの競合が発生する可能性が高くなります。
他の人に見せる必要のないローカルの実験的ブランチ (複製されたリポジトリもブランチと見なすことができます) を持つことができます。つまり、アップストリームに何もプッシュしていない場合、重大な変更が開発者に影響を与える必要はありません。CVCS では、重大な変更がまだある場合、それを修正するまでオフラインで作業し、それまでに変更をコミットする必要がある場合があります。このアプローチは、バージョン管理をセーフティ ネットとして使用する目的を効果的に無効にしますが、CVCS では必要悪です。
今日の世界では、企業は通常、オフショアの開発者と協力しています (または、自宅で仕事をしたい場合)。DVCS を使用すると、誰もが独自のリポジトリを持っているため、信頼できるネットワーク接続が不要になるため、この種のプロジェクトに役立ちます。
…そして、通常は回避策があるいくつかの欠点:
誰が最新のリビジョンを持っていますか? CVCS では、通常、トランクに最新のリビジョンが含まれていますが、DVCS ではそれが明白ではない場合があります。回避策は、プロジェクトの開発者が作業をマージするレポに合意する必要がある行動規則を使用することです。
悲観的ロック、つまりチェックアウト時にファイルがロックされることは、通常、DVCS のリポジトリ間で発生する可能性がある同時実行性のために不可能です。バージョン管理にファイル ロックが存在する理由は、開発者がマージの競合を回避したいからです。ただし、ロックには、ロング トランザクション モデルのように 2 人の開発者が同じコードで同時に作業することができず、マージの競合に対する完全な保証がないため、開発が遅くなるという欠点があります。バージョン管理に関係なく、大きなマージ競合に対処する唯一の健全な方法は、優れたコード アーキテクチャ (低結合、高結束など) を持ち、コードへの影響が少なくなるように作業タスクを分割することです (言うは易く行うは難しです)。 .
プロプライエタリなプロジェクトでは、リポジトリ全体が公開されると悲惨なことになります。不満を持った、または悪意のあるプログラマーが複製されたリポジトリを入手した場合はなおさらです。ソース コードの漏えいは、プロプライエタリ ビジネスにとって深刻な問題です。一部の CM システム (ClearCase など) はそのアクセスを制限しようとしますが、DVCS ではリポジトリのクローンを作成するだけでよいため、これが単純になります。しかし、私の意見では、企業文化に十分な量の機能不全がある場合、ソースコードの漏洩を防ぐのに役立つバージョン管理は世界中にありません。
適切な SCM を探しているときに、次のリンクが非常に役立つことがわかりました。
ある程度、2 つのスキームは同等です。
そうは言っても、伝統的にDVCSが非常にうまく機能し、ほとんどの集中化されたVCSが少しハッシュすることがいくつかあります。これらの中で最も重要なのはおそらく分岐です。DVCS を使用すると、リポジトリの分岐や不要になった分岐のマージが非常に簡単になり、その間も履歴を追跡できます。中央集権的なスキームがこれに問題を起こす特別な理由はありませんが、歴史的に見て、誰もまだそれを完全に理解していないようです. それが実際に問題になるかどうかは、開発をどのように組織するかによって異なりますが、多くの人にとっては重要な考慮事項です。
DVCS のもう 1 つの利点は、オフラインで動作することです。私はそれを実際にあまり使用したことがありません。私はほとんどの場合、オフィス (ローカル ネットワーク上にリポジトリがあるため) または自宅 (ADSL があるため) で開発を行っています。旅行中にラップトップで多くの開発を行う場合は、これがより考慮される可能性があります。
実際には、DVCS に固有の落とし穴はそれほど多くありません。プッシュせずにコミットでき、プライベートで物事を簡単に磨くことができるため、人々は静かになる傾向がわずかに大きくなりますが、それを除けば、それほど多くの問題はありません. これは、通常、開発のパッチ トレーディング モデルに精通しているオープン ソース開発者が相当数いるためかもしれませんが、新しいクローズド ソース開発者もかなり早く物事を理解するようです。
私はSubversionを何年も使用してきましたが、本当に満足しています。
その後、GITの話題が始まり、テストする必要がありました. そして私にとって、主なセールス ポイントは分岐でした。ああ少年。これで、リポジトリをクリーンアップしたり、いくつかのバージョンに戻ったり、Subversion を使用したときに行ったばかげたことをしたりする必要がなくなりました。すべてがdvcsで安いです。私は化石と git しか試したことはありませんが、perforce、cvs、および subversion を使用しました。dvc はすべて非常に安価な分岐とタグ付けを備えているようです。すべてのコードを片側にコピーする必要がなくなるため、マージが簡単になります。
どの dvcs も中央サーバーでセットアップできますが、得られるものはとりわけ
好きな小さな変更をチェックインできます。Linus が言うように、今行ったことを説明するために複数の文を使用する必要がある場合は、やりすぎです。誰にも大量のデータをダウンロードさせることなく、コード、ブランチ、マージ、クローン、およびテストをすべてローカルで実行できます。最終的な変更を中央サーバーにプッシュするだけです。
また、ネットワークなしで作業できます。
要するに、バージョン管理を使用することは常に良いことです。dvcs を使用すると (KB と帯域幅の点で) 安価で、より楽しく使用できると思います。
Git をチェックアウトするには: http://git-scm.com/
Fossil をチェックアウトするには: http://www.fossil-scm.org
Mercurial をチェックアウトするには: https://www.mercurial-scm.org
今、私が推奨できるのは dvcs システムだけです。中央サーバーを簡単に使用できます。
分散VCSは多くの点で魅力的ですが、私の会社にとって重要な1つの欠点は、マージ不可能なファイル（通常、Excelドキュメントなどのバイナリ）の管理の問題です。Subversionは、「svn：needs-lock」プロパティをサポートすることでこれに対処します。つまり、編集する前に、マージできないファイルのロックを取得する必要があります。それはうまくいきます。ただし、そのワークフローには、DVCSの概念に反する集中型リポジトリモデルが必要です。
したがって、DVCSを使用する場合は、マージできないファイルの管理にはあまり適していません。
主な問題 (明らかな帯域幅の問題は別として) は所有権です。
つまり、異なる（地理的な）サイトが他のサイトと同じ要素で作業していないことを確認してください。
理想的には、ツールが所有権をファイル、ブランチ、さらにはリポジトリに割り当てることができます。
この回答のコメントに答えるには、ツールで誰が何を所有しているかを教えてから、(電話、IM、またはメールで) 離れたサイトと通信する必要があります。
所有権メカニズムがない場合...「通信」しますが、多くの場合遅すぎます;) (つまり、同じブランチ内の同一のファイルセットで並行開発を行った後。コミットが乱雑になる可能性があります)
私にとって、これは個人的な好みに関する別の議論であり、本当に客観的であることはかなり難しい. 個人的には、他の DVCSよりもMercurialを好みます。私はMercurialが書かれているのと同じ言語でフックを書くのが好きで、ネットワーク オーバーヘッドが小さくなります。
最近では誰もが DVCS の優れた点について流行に乗っていますが、Craig のコメントは重要です。DVCS では、各人がブランチの全履歴を持っています。大量のバイナリ ファイル (画像ファイルや FLA など) を操作している場合、これには大量のスペースが必要であり、差分を作成することはできません。
Mercurial (およびその他の DVCS) は中央集中型のものよりも洗練されていると感じています。たとえば、Mercurial でブランチをマージするとブランチの完全な履歴が保持されますが、SVN ではブランチ ディレクトリに移動して履歴を確認する必要があります。
単独の開発者のシナリオであっても、分散 SCM のもう 1 つのメリットは、私たちの多くと同様に、複数のマシンで作業している場合です。
一般的なスクリプトのセットがあるとします。作業している各マシンにクローンがある場合は、スクリプトをオンデマンドで更新および変更できます。それはあなたに与えます：
集中型システムは、開発を行うために別々のブランチを使用することを必ずしも妨げません。コード ベースの真のコピーが 1 つだけである必要はありません。むしろ、さまざまな開発者やチームがさまざまなブランチを持つことができ、レガシー ブランチが存在する可能性があります。
一般的には、リポジトリが集中管理されることを意味しますが、これは、バックアップする場所とストレージを管理する場所が 1 か所しかないことを意味するため、有能な IT 部門を持つ企業では一般的に有利です。
W. Craig Trader の回答はそのほとんどを要約していますが、個人のワーク スタイルも同様に大きな違いを生むことがわかりました。私が現在働いている場所では、Subversion を唯一の真のソースとして使用していますが、多くの開発者は個人のマシンで git-svn を使用して、私たちが抱えているワークフローの問題 (管理の失敗ですが、それは別の話です) を補っています。いかなる場合でも。実際には、どの機能セットが最も生産性を高めるか、組織が必要とするもの (集中認証など) とのバランスを取ることが重要です。