私はSubversionオタクですが、なぜMercurialやGit、その他のDVCSを検討する必要があるのですか？
分散バージョン管理システム（DVCS）の利点を理解しようとしています。
私は Subversion Re-education および Martin Fowler による この記事 が非常に有用であることを発見しました。
Mercurialおよびその他のDVCSは、変更セットとローカルコミットを使用してコードを処理する新しい方法を推進しています。それは地獄と他のコラボレーションの問題をマージすることを防ぎます
私は 継続的インテグレーション を実践しているため、これによる影響はありません。実験を行わない限り、プライベートブランチで単独で作業することはできません。トランクからマージされたバグを修正するすべてのメジャーバージョンにブランチを使用します。
Mercurialを使用すると、中尉を確保できます
これはLinuxのような非常に大規模なプロジェクトに役立つことを理解していますが、小規模で高度なコラボレーションチーム（5〜7人）にはその価値がありません。
Mercurialはより高速で、必要なディスク容量が少なく、完全なローカルコピーにより、より高速なログと差分操作が可能になります。
私が取り組んでいる非常に大規模なプロジェクトでも、SVNの速度やスペースの問題に気づかなかったので、私はこれも気にしていません。
元のSVNオタクからの個人的な経験や意見を求めています。特にchangesetsの概念と全体的なperformanceブーストに関して測定しました。
UPDATE（1月12日）：試してみる価値があると確信しました。
更新（6月12日）：私はMercurialにキスをし、私はそれが好きでした。彼の地元のチェリーの味はコミットします。 Mercurialにキスするだけでキスをしました。私のSVNサーバーがそれを気にしないことを望みます。それはとても間違っていた。それはとても正しいと感じました。 今夜私が恋をしているという意味ではありません。
最終更新（7月29日）： Eric Sink の次の本 Version例による制御 。彼は私を納得させました。 Mercurialに行きます。
注：現在の質問への回答については、 "EDIT"を参照してください
まず、Joel Spolskyによる Subversion Re-education を読んでください。あなたの質問のほとんどはそこで答えられると思います。
もう1つの推奨事項、Gitに関するLinus Torvaldsの講演： http://www.youtube.com/watch?v=4XpnKHJAok8 。これもあなたの質問のほとんどに答えるかもしれません、そしてそれはかなり面白いものです。
ところで、私がかなり面白いと思うこと：Subversionの元の作成者の2人であるBrian FitzpatrickとBen Collins-Sussmanも、1つのGoogleトークで、SubversionがMercurial（および一般にDVCS）よりも劣っていることを「申し訳ありません」と言っています。
現在、IMOと一般的に、チームダイナミクスはどのDVCSでもより自然に発達します。優れた利点は、次のことを意味するため、オフラインでコミットできることです。
- サーバーと接続に依存しないため、時間が短縮されます。
- コミットできるようにするためだけにインターネットアクセス（またはVPN）を取得できる場所の奴隷ではありません。
- 誰もがサーバーだけでなく、すべて（ファイル、履歴）のバックアップを持っています。 つまり、誰でもサーバーになることができます。
- 必要な場合は、他の人のコードを混乱させることなく強制的にコミットできます。コミットはローカルです。コミットしている間、お互いのつま先を踏みません。コミットするだけで他人のビルドや環境を壊すことはありません。
- 「コミットアクセス」を持たないユーザーはコミットできます（DVCSでのコミットはコードのアップロードを意味しないため）。コントリビューションの障壁を下げ、変更をプルするか、インテグレーターでないかを決定できます。
- DVCSがこれを不可欠にするため、自然なコミュニケーションを強化できます。Subversionでは、代わりにコミットレースが行われ、コミュニケーションを強制しますが、作業を妨害します。
- コントリビューターはチームを組んで独自のマージを処理できるため、最終的にはインテグレーターの作業が減ります。
- コントリビューターは他のユーザーに影響を与えることなく独自のブランチを持つことができます（ただし、必要に応じてそれらを共有することができます）。
ポイントについて：
- 地獄のマージはDVCSlandには存在しません。処理する必要はありません。 次のポイントを参照してください。
- DVCSでは、全員が「ブランチ」を表します。つまり、変更がプルされるたびにマージが行われます。名前付きブランチは別のものです。
- 必要に応じて継続的インテグレーションを使い続けることができます。 IMHOは必要ありませんが、なぜ複雑さを増すのでしょうか。テストを文化/ポリシーの一部として維持してください。
- Mercurialはいくつかの点でより高速で、gitは他の点でより高速です。実際にはDVCSまでではなく、特定の実装AFAIKまでです。
- あなただけでなく、誰もが常に完全なプロジェクトを手にするでしょう。分散されたものは、ローカルでコミット/更新できることと関係があり、コンピューターの外部からの共有/取得は、プッシュ/プルと呼ばれます。
- もう一度、Subversion Re-educationをお読みください。 DVCSの方が簡単で自然ですが、DVCSは異なります。cvs/ svn ===すべてのバージョン管理のベースであると考えないでください。
私はいくつかのドキュメントをJoomlaプロジェクトに寄稿して、DVCSへの移行の説教を支援しました。here集中型と分散型を示す図をいくつか作成しました。
集中型
一般的な方法で配布
最大限に配布
図には、まだ「集中型リポジトリ」があり、これは集中型バージョン管理ファンのお気に入りの引数の1つです。「集中型リポジトリはまだ集中型です」すべてが同意します（たとえば、公式のgithubリポジトリ）。ただし、これは必要に応じていつでも変更できます。
これが、DVCSを使用したオープンソースプロジェクト（大規模なコラボレーションを行うプロジェクトなど）の一般的なワークフローです。
Bitbucket.org はMercurialと同等のgithubに相当します。無制限のスペースを持つ無制限のプライベートリポジトリがあることを知ってください。チームが5未満の場合は、無料で使用できます。
DVCSを使用することに納得できる最良の方法は、DVCSを試すことです。svn/ cvsを使用した経験のあるすべてのDVCS開発者は、それが価値があること、そしてそれなしですべての時間を生き延びた方法を知らないことを伝えます。
[〜＃〜] edit [〜＃〜]：2番目の編集に答えるには、DVCSを使用して、別のワークフローを持っていることを繰り返します。 ベストプラクティスのため、試さない理由を探らないようにアドバイスします。OOPは不要であると人々が主張するときのように感じます彼らが常にパラダイムXYZで行うことで複雑なデザインパターンを回避できるため、とにかくメリットがあります。
試してみてください。「プライベートブランチ」での作業が実際にどのように優れているかがわかります。最後が真である理由を私が言える1つの理由は、コミットする恐怖を失うため、いつでも適切に動作し、作業できるようになるからです。より自然な方法。
「マージ地獄」については、「実験を行っているのでない限り」と言いますが、「実験している場合でも、+ maintaing + 同時に改良されたv2.0で動作している 」と言います。前に言ったように、マージ地獄は存在しません。
- コミットするたびに、名前のないブランチが生成され、変更が他の人の変更に出会うたびに、自然なマージが発生します。
- DVCSはコミットごとにより多くのメタデータを収集するため、マージ中に発生する競合は少なくなります。そのため、「インテリジェントマージ」と呼ぶこともできます。
- マージの競合にぶつかった場合、これを使用できます。
また、プロジェクトのサイズは関係ありません。Subversionから切り替えたとき、実際には一人で作業しているときに既にメリットが見られましたが、すべてが適切に感じられました。 changesets（厳密にはリビジョンではなく、コードベースの状態から分離された、コミットを含む特定のファイルの特定の変更セット）により、コードベース全体ではなく、特定のファイルグループに対して行っていたことを正確に視覚化します。
チェンジセットの動作とパフォーマンスの向上について。 github network graph に示されているsvnからのmootoolsプロジェクトスイッチを例に挙げて、それを説明します。
前
後
あなたが見ているのは、開発者が他の人のコードを壊すことを恐れずに、コミットしながら自分の仕事に集中できることです。プッシュ/プルした後、他の人のコードを壊すことを心配しています（DVCS：最初にコミットし、次にプッシュ/プルしてから更新します） ）しかし、ここではマージの方が賢いので、マージが行われないことがよくあります...まれにマージの競合が発生した場合でも、5分以内で修正できます。
Mercurial/gitの使い方を知っている人を探して、実際に説明するように彼/彼女に言ってください。 Mercurialをデスクトップとbitbucketアカウントで使用して、マージする方法を示しながら、友達とコマンドラインで約30分費やし、ばかばかしい時間で修正する方法を確認するために競合を作り出すことで、私は示すことができましたそれらはDVCSの真の力です。
最後に、Windowsを使用している場合は、git + githubではなくMercurial + bitbucketを使用することをお勧めします。 Mercurialも少しシンプルですが、gitはより複雑なリポジトリ管理のためのより強力です（例 git rebase ）。
いくつかの追加の推奨読み：
- 分散リビジョン管理システム：Git対Mercurial対SVN
- Git対Mercurial：リラックスしてください
- 分散バージョン管理とGit [パート1] ＆ 分散バージョン管理とGit [パート2]
- Git/Mercurial vs. Subversion：Fight！
- DVCS vs Subversionスマックダウン、ラウンド
- GitよりもMercurialが好きな理由 （ パート1 、 パート2 ）
- Gitによる貢献：Git VCSとのオープンソースコラボレーションの摩擦の軽減
- "これまでにDVCSはどのように機能しましたか？" -Joomlaに投稿してください！ Joomla！にMercurialとgitを実験的に採用した後にフィードバックを求めるFramework Developmentメーリングリスト。プラットフォームプロジェクト
- DVCS分岐（Mercurialを使用） -DVCSでの分岐の様子の詳細で例指向の紹介。これは、これらのシステムでおそらく最も重要な機能です。
あなたが言っていることは、とりわけあなたが本質的に単一のブランチにとどまるなら、あなたは分散バージョン管理が必要ないということです。
それは本当ですが、それはあなたの働き方に不必要に強い制限であり、複数のタイムゾーンの複数の場所にうまく拡張できないものではありませんか？中央のSubversionサーバーはどこに配置する必要がありますか。また、なんらかの理由でサーバーがダウンした場合、全員が家に帰る必要がありますか？
DVCSはSubversion向けであり、BittorrentはFTP向けです
（技術的には、合法ではありません）。おそらく、それが終わったと思うなら、なぜそれがそんなに大きな飛躍であるのか理解できるでしょうか？
私にとっては、gitへの切り替えにより、すぐに
- バックアップが簡単になりました（「git remote update」で完了です）
- 中央リポジトリにアクセスせずに作業する場合、小さなステップをコミットするのが簡単になります。中央リポジトリをホストしているネットワークに戻ったときに、作業して同期します。
- より高速なHudsonビルド。更新よりもgit pullを使用する方がはるかに高速です。
それで、bittorrentがftpより優れている理由を考えて、あなたの立場を再考してください:)
注：ftpがbittorrentよりも高速であるユースケースがあることが言及されています。これは、お気に入りのエディターが保持するバックアップファイルがバージョン管理システムよりも速く使用できるのと同じように当てはまります。
分散バージョン管理システムのキラー機能は、分散部分です。リポジトリから「作業コピー」をチェックアウトせず、リポジトリのコピー全体を複製します。強力なメリットがあるため、これは非常に大きなメリットです。
次のようなインターネットにアクセスできない場合でも、バージョン管理のメリットを享受できます...これは残念ながら、DVCSが素晴らしい理由として、過度に使用され、宣伝されすぎています。カエルに雨が降り始めるのと同じくらい頻繁にインターネットアクセスなしでコーディングしていることに気づくので、これは強力なセールスポイントではありません。ローカルリポジトリを使用する本当の理由はキラーですマスターリポジトリにプッシュされる前にコミット履歴を完全に制御できます。
これまでにバグを修正し、次のようなものになりました：
r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...
等々。そのような履歴は乱雑です---実際には1つの修正しかありませんでしたが、デバッグステートメントの追加や削除など、不要なアーティファクトを含む多くのコミットに実装が広がっています。 SVNのようなシステムでは、履歴をクリーンに保つためにすべてが機能するまで、コミットしない（!!!）その場合でも、ミスは回避され、バージョン管理によって大量の作業が保護されていない場合、マーフィーの法則があなたを残忍にするのを待っています。
リポジトリのローカルクローンを所有していると、これを修正します。これは、「fix it」と「oops」を継続的にローリングして履歴を書き直すことができるためです。 "は"バグ修正 "コミットにコミットします。 1日の終わりに、次のような1つのクリーンなコミットがマスターリポジトリに送信されます。
r321 Fixed annoying bug.
本来あるべき姿です。
ブランチモデルと組み合わせると、履歴を書き換える機能がさらに強力になります。開発者は、ブランチ内で完全に分離された作業を行うことができ、そのブランチをトランクに組み込むときは、あらゆる種類の興味深いオプションがあります。
単純なバニラmergeを実行します。すべてをいぼなどにもたらします。
rebaseを実行します。ブランチの履歴を並べ替えたり、コミットの順序を並べ替えたり、コミットを破棄したり、コミットを結合したり、コミットメッセージを書き直したりできます。コミットの編集や新しいコミットの追加も可能です。 分散バージョン管理システムはコードレビューを深くサポートしています。
プログラマーや将来の自分の正気のために、ローカルリポジトリで履歴を編集する方法を学んだ後、SVNをずっと使い続けました。私のSubversionクライアントはgit svn。
開発者とマネージャーがコミット履歴を編集管理できるようにすると、プロジェクトの履歴が改善され、クリーンな履歴で作業できるため、プログラマーとしての生産性が本当に向上します。この「リライト履歴」についてのすべての話があなたを怖がらせても、それがセントラル、パブリック、またはマスターリポジトリの目的であるので心配しないでください。歴史は、誰かがそれを他の人々が引っ張っているリポジトリのブランチに持ってくるまで、書き直されるかもしれません（そしてそうすべきです！）。その時点で、歴史はまるで石板に刻まれたように扱われるべきです。
dukofgamingsの答えはおそらく可能な限り良いですが、別の方向からこれに取り組みたいと思います。
あなたの言ったことは絶対に真実であり、良い実践を適用することで、DVCSが修正するように設計された問題を回避できると仮定しましょう。これは、DVCSが何の利点も提供しないことを意味しますか？人々悪臭以下のベストプラクティス。人々は台無しに行くです。では、なぜ一連の問題を修正するように設計されたソフトウェアを回避し、代わりに人々が事前に予測できないことを実行することを頼むことを選択するのでしょうか？
はい、Subversionで大きなコミットをマージしなければならないときは痛いです。しかし、これは素晴らしい学習経験でもあり、衝突のマージを回避するためにあらゆることを可能にします。つまり、 頻繁にチェックインする について学習します。早期の統合は、同じ場所にあるプロジェクトにとって非常に良いことです。誰もがそうしている限り、Subversionの使用はそれほど問題にはなりません。
たとえば、Gitは designed であり、分散作業の場合、独自のプロジェクトに取り組み、後で（最終的に）マージするために独自のフォークを作成することを奨励します。それはではなく、OPが求めている「小規模で高度なコラボレーションチーム」への継続的な統合のために特別に設計されました。むしろ逆です、考えてみてください。同じコードで共同作業している同じ部屋に座っているだけなら、その派手な分散機能を使用することはできません。
そのため、同じ場所に配置されたCIを使用するチームの場合、分散システムを使用するかどうかはそれほど重要ではないと思います。味と経験の問題に要約されます。
自分の知識に挑戦し続ける必要があるからです。あなたはSubversionが好きで、長年使っていてとても満足しているので理解できます。
使い始めた頃は、それが一番の選択だったと思います。しかし、時間の経過とともに他のツールも登場し、今では自分の暇なプロジェクトでもgitを好みます。
そしてSubversionにはいくつかの欠点があります。例えば。ディスク上のディレクトリの名前を変更しても、リポジトリでは名前が変更されません。ファイルの移動はサポートされていません。ファイルの移動/コピー操作や削除操作、ファイルの移動/名前変更の変更のマージは困難です。また、マージ追跡は実際にはシステムに組み込まれているのではなく、回避策の形で実装されています。
Gitはこれらの問題を解決します（ファイルが移動されたかどうかを自動的に検出することを含め、それが事実であることを伝える必要すらありません）。
一方、gitでは、Subversionのように個々のディレクトリレベルで分岐することはできません。
だから私の答えは、あなたは代替案を調査し、それがあなたが知っているものよりもあなたのニーズによく合うかどうかを見て、それから決めるべきだということです。
パフォーマンスに関しては、あるブランチから別のブランチに切り替えたり、あるリビジョンから別のリビジョンにジャンプしたりする必要がある場合、Gitまたはその他のDVCSはSVNよりも大きな利点があります。すべてがローカルに保存されているので、SVNの場合よりもはるかに速いです。
これだけで切り替えられます！
「ベストプラクティスを適用することでDVCSは必要ない」という考えにとらわれず、SVNワークフローが1つのワークフローであり、1セットのベストプラクティスがあり、GIT/Hgワークフローは別のワークフローであると考えてみてください。異なる一連のベストプラクティスを使用します。
git bisect（およびメインリポジトリへの影響すべて）
Gitでは、非常に重要な原則として、git bisectを使用してバグを見つけることができます。これを行うには、動作することがわかっている最後に実行したバージョンと、失敗することがわかっている最初に実行したバージョンを取得し、（Gitの助けを借りて）バイナリ検索を実行して、バグの原因となったコミットを特定します。これを行うには、変更履歴全体に、バグ検索に干渉する可能性のある他のバグが比較的少ないことが必要です（信じられないかもしれませんが、これは実際には実際に非常にうまく機能し、Linuxカーネル開発者は常にこれを行います）。
git bisect機能を実現するには、独自の新しい機能機能ブランチを開発し、それをリベースして履歴をクリーンアップします（これにより、 t履歴に動作していない既知のリビジョンがあります-一連の変更で問題を修正できます）。その後、機能が完了したら、機能履歴のあるメインブランチにマージします。
また、これを機能させるには、メインブランチのどのバージョンから機能ブランチを開始するかについての規律が必要です。 masterブランチの現在の状態から始めることはできません。これには無関係なバグがある可能性があるため、カーネルコミュニティでのアドバイスは、最新の安定したバージョンのカーネルから作業を開始することです（大きな機能について） ）、または最新のタグ付きリリース候補から作業を開始します。
また、機能ブランチをサーバーにプッシュして中間の進捗状況をバックアップすることもできます。また、機能ブランチをサーバーにプッシュして他のユーザーと共有し、機能が完了する前に、機能が完了する前にフィードバックを引き出すことができます。コードをコードベースの永続的な機能に変え、プロジェクトの全員*が対処する必要があります。
gitworkflows manページは、Gitが設計されているワークフローの入門として適しています。また GitがXより優れている理由 はgitワークフローについて説明しています。
大規模な分散プロジェクト
優れたプラクティスと優れたデザインの習慣を備えた非常に協力的なチームの副官が必要なのはなぜですか？
Linuxのようなプロジェクトでは、地理的に分散している非常に多くの人々が関与しているため、会議室を共有する小さなチームほど高度に共同作業するのは困難です。 （Microsoft Windowsのような大規模な製品を開発する場合、全員が同じ建物にいる場合でも、チームが大きすぎて、中央のVCSを代理人なしで機能させるコラボレーションのレベルを維持できないと思います。）
一緒に使ってみませんか？現在のプロジェクトでは、CVSの使用を余儀なくされています。ただし、機能開発を行うために、ローカルのgitリポジトリも保持しています。自分のマシンでさまざまなソリューションを試したり、作業中のバージョンを維持したりできるので、これは両方の世界で最高です。これにより、機能を以前のバージョンにロールバックしたり、コードをめちゃくちゃにするときに問題に陥ることなくいくつかのアプローチを試すことができます。中央リポジトリがあると、中央リポジトリを持つ利点が得られます。
私はDVCSの個人的な経験はありませんが、ここでの回答といくつかのリンクされたドキュメントから収集したものから、DVCSとCVCSの間の最も基本的な違いは、使用されている動作モデルです
DVCS
DVCSの動作モデルは、あなたが分離開発を実行していることです。チームの他のメンバーにリリースすることを決定する瞬間まで、他のすべての変更とは切り離して新しい機能/バグ修正を開発しています。それまでは、他の誰も気にしないので、好きなチェックインを行うことができます。
CVCS
CVCS（特にSubversion）の作業モデルは、あなたが共同開発を実行していることです。他のすべてのチームメンバーと直接コラボレーションして新しい機能/バグ修正を開発しており、すべての変更がすべてのユーザーにすぐに利用できます。
その他の違い
リビジョンとチェンジセットなど、svnとgit/hgのその他の違いは偶発的なものです。リビジョンに基づいてDVCS（Subversionにあるため）またはチェンジセットに基づいてCVCS（Git/Mercurialにあるため）を作成することは十分に可能です。
特定のツールをお勧めするつもりはありません。それは、主にあなた（そしてあなたのチーム）が最も使いやすい作業モデルに依存しているためです。
個人的には、CVCSでの作業に問題はありません。
- 不完全ではあるがコンパイル可能な状態にするのに問題はないので、チェックインの心配はありません。
- マージ地獄を経験したとき、それは
svnとgit/hgの両方で発生する状況でした。たとえば、一部のソフトウェアのV2は、V3の開発中に別のVCSを使用して別のチームによって保守されていました。場合によっては、バグ修正をV2 VCSからV3 VCSにインポートする必要があります。これは、基本的にV3 VCSで非常に大規模なチェックインを実行することを意味します（すべてのバグ修正が1つのチェンジセットに含まれます）。理想的ではなかったと思いますが、異なるVCSシステムを使用することは管理上の決定でした。