集中型と分散型バージョン管理システムの比較
集中型と分散型バージョン管理システム（DVCS）を使用した場合の利点と欠点は何ですか？ DVCSの問題に遭遇しましたか？これらの問題からどのように保護しましたか？ ディスカッションツールにとらわれず、炎を最小限に抑えます。
利用可能なDVCSツールを知りたい人のために、最も有名なフリー/オープンソースDVCSのリストを以下に示します。
- Git 、（Cで記述） LinuxカーネルおよびRuby on Rails によって使用されます。
- Mercurial 、 MozillaおよびOpenJDK で使用される（Pythonで記述）。
- Bazaar 、（Pythonで作成された） buntu開発者 によって使用されます。
- Darcs 、（Haskellで記述）。
分散バージョン管理システム（DVCS）は、集中型VCSとは異なる問題を解決します。それらを比較することは、ハンマーとドライバーを比較するようなものです。
中央集中型VCS システムは、祝福された、それゆえ良い1つの真のソースがあることを意図して設計されています。すべての開発者がそのソースから作業（チェックアウト）し、変更を追加（コミット）すると、同様に祝福されます。 CVS、Subversion、ClearCase、Perforce、VisualSourceSafe、および他のすべてのCVCSの唯一の本当の違いは、各製品が提供するワークフロー、パフォーマンス、統合にあります。
Distributed VCS システムは、あるリポジトリが他のリポジトリと同等であり、あるリポジトリから別のリポジトリへのマージが単なる通信の別の形式であるという意図で設計されています。どのリポジトリを信頼すべきかについてのセマンティック値は、ソフトウェア自体ではなく、プロセスによって外部から課せられます。
どちらのタイプを使用するかという本当の選択は組織です。プロジェクトまたは組織が集中管理を必要とする場合、DVCSはスターターではありません。開発者が、中央リポジトリへの安全なブロードバンド接続なしで、国/世界中で働くことが期待される場合、DVCSがおそらく救いです。両方が必要な場合は、fsck'dです。
分散システムが信頼できるコピーを許可しないと考える人にとっては、分散システムが信頼できるコピーを持っている場所がたくさんあることに注意してください。完璧な例は、おそらくLinusのカーネルツリーです。確かに多くの人が自分のツリーを持っていますが、それらのほとんどすべてがLinusの木に向かって流れます。
つまり、分散SCMは、さまざまなことを行う多くの開発者にとってのみ有用であると考えていましたが、最近、集中型リポジトリで分散型リポジトリでできることは何でもできると判断しました。
たとえば、あなたがあなた自身の個人プロジェクトに取り組んでいるソロ開発者だとしましょう。中央リポジトリは明らかな選択かもしれませんが、このシナリオを検討してください。ネットワークアクセス（飛行機、公園など）から離れているため、プロジェクトに取り組みたい。ローカルコピーがあるので正常に動作できますが、ある機能を終了して別の機能に移動したい、または修正するバグなどを見つけたので、本当にコミットしたいです。重要なのは、一元化されたレポでは、すべての変更をまとめて非論理的な変更セットでコミットするか、後で手動で分割するかのいずれかです。
分散型レポジトリを使用すると、通常どおり業務に従事し、コミットして先に進みます。再びネットにアクセスできるようになったら、「1つの真のレポ」にプッシュしても何も変わりません。
分散リポジトリに関する他の素晴らしいことは言うまでもありません：常に利用可能な完全な履歴。ネットから離れているときにリビジョンログを見る必要がありますか？バグがどのように導入されたかを確認するには、ソースに注釈を付ける必要がありますか？分散リポジトリですべて可能。
分散型と集中型の両方が所有権や信頼できるコピー、またはそのようなものであると信じないでください。分散された現実は、SCMの進化における次のステップです。
実際の比較ではありませんが、大きなプロジェクトで使用しているものは次のとおりです。
集中型VCS
Apache、GCC、Ruby、MPlayer、Zope、Plone、Xiph、FreeBSD、WebKit、...
[〜＃〜] cvs [〜＃〜]
CVS
分散VCS
Linuxカーネル、KDE、Perl、Ruby on Rails、Android、Wine、Fedora、X.org、Mediawiki、Django、VLC、Mono、Gnome、Samba、CUPS、GnuPG、Emacs ELPA .. 。
MozillaおよびMozdev、OpenJDK（Java）、OpenSolaris、ALSA、NTFS-3G、Dovecot、MoinMoin、mutt、PETSc、Octave、FEniCS、Aptitude、Python、XEmacs、Xen、Vim、Xine ...
Emacs、Apt、Mailman、MySQL、SquidなどもUbuntu内で宣伝されています。
ghc、ion、xmonad、... Haskellコミュニティ内で人気があります。
SQLite
W。Craig Trader DVCSとCVCSについてこれを言った：
両方が必要な場合は、fsck'dです。
両方を使用する場合、fsck'dとは言いません。実際には、DVCSツールを使用する開発者は通常、変更をマージ（またはプルリクエストを送信）して中央の場所（通常はリリースリポジトリのリリースブランチ）にマージしようとします。 DVCSを使用する開発者には皮肉がありますが、最終的には集中型ワークフローに固執しているため、分散型アプローチが集中型よりも本当に優れているのか疑問に思うかもしれません。
DVCSには、CVCSよりもいくつかの利点があります。
一意に認識可能なコミットの概念により、ピア間でパッチを送信するのが簡単になります。つまりパッチをコミットとして作成し、それを必要とする他の開発者と共有します。後で全員がマージしたい場合、その特定のコミットが認識され、ブランチ間で比較できるため、マージの競合の可能性が低くなります。開発者は、使用しているバージョン管理ツールに関係なく、USBスティックまたは電子メールで相互にパッチを送信する傾向があります。残念ながら、CVCSの場合、バージョン管理はコミットを個別に登録するため、変更が同じであることを認識できず、マージ競合の可能性が高くなります。
他のユーザーに表示する必要のないローカルの実験ブランチ（クローンリポジトリもブランチと見なすことができます）を作成できます。つまり、アップストリームに何もプッシュしていなければ、重大な変更が開発者に影響を与える必要はありません。 CVCSでは、まだ重大な変更がある場合は、修正するまでオフラインで作業し、それまでに変更をコミットする必要があります。このアプローチは、バージョン管理をセーフティネットとして使用する目的を事実上無効にしますが、CVCSに必要な悪です。
今日の世界では、企業は通常、オフショア開発者と仕事をしています（または、さらに良い場合は、自宅で仕事をしたいと考えています）。 DVCSを使用すると、誰もが独自のリポジトリを持っているため、信頼性の高いネットワーク接続の必要性がなくなるため、この種のプロジェクトを支援します。
…および通常回避策があるいくつかの欠点：
誰が最新のリビジョンを持っていますか？ CVCSでは、トランクは通常最新のリビジョンを持っていますが、DVCSではそれは明白ではないかもしれません。回避策は、プロジェクト内の開発者が作業をマージするレポの合意に達する必要があるという行動規則を使用することです。
悲観的なロック、つまりチェックアウト時にファイルがロックされることは、DVCSのリポジトリ間で発生する可能性のある同時実行性のため、通常は不可能です。バージョン管理にファイルロックが存在する理由は、開発者がマージの競合を避けたいためです。ただし、2人の開発者が長いトランザクションモデルのように同じコードで同時に作業することはできず、マージの競合に対する完全な保証ではないため、ロックには開発が遅くなるという欠点があります。バージョン管理に関係なく唯一の正しい方法は、大きなマージの競合に対抗することです（優れたコードアーキテクチャ（低結合、高凝集度など）を持ち、作業タスクを分割してコードへの影響を小さくすることです（これは言うより簡単です） 。
独自のプロジェクトでは、リポジトリ全体が公開されると悲惨なものになります。不満や悪意のあるプログラマーがクローンリポジトリを手に入れた場合はなおさらです。ソースコードの漏洩は、プロプライエタリビジネスにとって深刻な痛みです。リポジトリのクローンを作成するだけでよいので、DVCSのおかげでこれは単純になりますが、一部のCMシステム（ClearCaseなど）はそのアクセスを制限しようとします。しかし、私の意見では、企業文化に十分な機能不全がある場合、世界のバージョン管理はソースコードの漏洩を防ぐことはできません。
適切なSCMを検索中に、次のリンクが非常に役立つことがわかりました。
- より良いSCMイニシアティブ：比較 。約26のバージョン管理システムの比較。
- リビジョン管理ソフトウェアの比較 。技術的な違い、機能、ユーザーインターフェイスなどのトピックをカバーする約38のバージョン管理システムを比較するウィキペディアの記事。
- 分散バージョン管理システム 。別の比較ですが、主に分散システムに焦点を当てています。
ある程度まで、2つのスキームは同等です。
- ローカルコミットのたびに指定されたアップストリームリポジトリに変更を常にプッシュする場合、分散VCSは中央集中型を簡単にエミュレートできます。
- 集中型VCSは、通常、分散型を非常に自然にエミュレートすることはできませんが、その上で quilt のようなものを使用すると、非常に似たものを得ることができます。 Quiltは、慣れていない場合、アップストリームプロジェクトの上にある大規模なパッチセットを管理するためのツールです。ここでの考え方は、DVCSコミットコマンドは新しいパッチを作成することによって実装され、プッシュコマンドは集中型VCSに未処理のパッチをすべてコミットしてからパッチファイルを破棄することによって実装されるというものです。これは少し厄介に聞こえますが、実際には実際にはかなりうまく機能します。
そうは言っても、DVCSがこれまで非常にうまく機能していて、ほとんどの中央集中型VCSが少しハッシュを作成していることがいくつかあります。これらの中で最も重要なのはおそらく分岐です。DVCSを使用すると、リポジトリの分岐や不要になった分岐のマージが非常に簡単になり、その間履歴を追跡できます。中央集権化されたスキームがこれに問題を抱える理由は特にありませんが、歴史的には、まだ誰もそれを正しく理解していないようです。それが実際にあなたにとって問題であるかどうかは、あなたがどのように開発を組織するつもりであるかによりますが、多くの人々にとってそれは重要な考慮事項です。
DVCSのもう1つの利点は、オフラインで動作することです。私はそれを実際に使ったことがありません。私は主にオフィス（つまりリポジトリがローカルネットワーク上にある）または自宅（つまりADSLがある）で開発を行っています。旅行中にラップトップで多くの開発を行う場合、これはあなたにとってより考慮すべきことかもしれません。
実際には、DVCSに固有の落とし穴はあまりありません。プッシュせずにコミットでき、プライベートで物事を磨くのは簡単であるため、人々は静かになる傾向がわずかにありますが、それ以外はあまり問題がありません。これは、開発のパッチトレーディングモデルに通常精通している多数のオープンソース開発者がいるためかもしれませんが、クローズドソースの開発者も適度に迅速に対応できるようです。
分散型VCSは多くの点で魅力的ですが、私の会社にとって重要な欠点の1つは、マージできないファイル（通常はバイナリ、たとえばExcelドキュメント）の管理の問題です。 Subversionは、「svn：needs-lock」プロパティをサポートすることでこれを処理します。つまり、編集する前に、マージできないファイルのロックを取得する必要があります。うまくいきます。ただし、そのワークフローには集中リポジトリモデルが必要であり、DVCSの概念に反しています。
したがって、DVCSを使用する場合、マージできないファイルの管理にはあまり適していません。
私はもう何年もSubversionを使用していますが、本当に嬉しかったです。
その後、GITの話題が始まり、私はそれをテストする必要がありました。そして私にとって、主なセールスポイントは分岐でした。ああ少年。これで、リポジトリをクリーンアップする必要がなくなり、Subversionを使用するときに行ったいくつかのバージョンやバカげた作業に戻る必要がなくなりました。 dvcsではすべてが安価です。 Fossilと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システムのみを推奨できます。また、中央サーバーを簡単に使用できます
主な問題は（明らかな帯域幅の問題は別として）所有権です。
それは、異なる（地理的）サイトが他のサイトと同じ要素で作業していないことを確認することです。
理想的には、ツールはファイル、ブランチ、またはリポジトリに所有権を割り当てることができます。
この回答のコメントに答えるには、誰が何を所有しているのかをツールに伝えて、then（電話、IM、またはメールを介して）通信します遠くのサイト。
所有権のメカニズムがない場合は、「通信」しますが、遅すぎることがよくあります;）（つまり、同じブランチ内の同じファイルセットで並行開発を行った後。コミットが乱雑になる可能性があります。 ）
最近の誰もがDVCSがどのように優れているかについて時流に乗っていますが、クレイグのコメントは重要です。 DVCSでは、各人がブランチの全履歴を持っています。多数のバイナリファイル（たとえば、画像ファイルやFLA）を使用している場合、これには膨大なスペースが必要であり、差分を作成することはできません。
Mercurial（およびその他のDVCS）は、集中型のものよりも洗練されていると感じています。たとえば、Mercurialでブランチをマージするとブランチの完全な履歴が保持されますが、SVNでは履歴を表示するにはブランチディレクトリに移動する必要があります。
ソロ開発者のシナリオでも分散SCMのもう1つの利点は、多くの私たちのように、複数のマシンを使用している場合です。
一般的なスクリプトのセットがあるとしましょう。作業している各マシンにクローンがある場合、オンデマンドでスクリプトを更新および変更できます。それはあなたに与えます：
- 特にsshキーによる時間節約
- 異なるシステム間の違いを分岐させる方法（例：Red Hat vs Debian、BSD vs Linuxなど）
集中化されたシステムは、必ずしも開発を行うために別々のブランチを使用することを妨げるわけではありません。コードベースの単一の真のコピーである必要はありません。むしろ、異なる開発者やチームが異なるブランチを持つことができ、レガシーブランチが存在する可能性があります。
通常、リポジトリが一元管理されるということですが、IT部門が有能な企業にとっては、バックアップする場所が1つだけで、ストレージを管理する場所が1つだけであるため、一般に利点です。
W. Craig Traderの答えはその大部分を要約していますが、個人的な仕事スタイルも大きな違いを生むと思います。私が現在働いているところでは、Sub TrueをOne True Sourceとして使用していますが、多くの開発者は個人のマシンでgit-svnを使用して、ワークフローの問題を補っています（管理の失敗ですが、それは別の話です）。いかなる場合でも。本当にどの機能セットが最も生産性を高めるのか、組織が必要とするもの（集中認証など）のバランスについてです。