gitやmercurialと比べてsvnのマージに違いはありますか？

私の理解から、SVNは「簡単に分岐できます。マージが難しい」。何故ですか？マージ方法に違いはありますか？

Mercurial（およびGit）が問題なくマージされ、Subversionが偽の競合を提示する非常に具体的な状況については、Stack Overflowの回答を参照してください。この状況は、いくつかのファイルの名前を変更するブランチで行われる単純なリファクタリングです。

tdammersの回答に関して、そこには多くの誤解があります。

• Subversion、Mercurial、およびGitはすべて、プロジェクトのリポジトリ全体のスナップショットを追跡します。それらをバージョン、リビジョン、またはチェンジセットと呼んでも違いはありません。これらはすべて、一連のファイルの論理的にアトミックなスナップショットです。

• マージのサイズに関しては、コミットのサイズに違いはありません。3つのシステムはすべて、標準のスリーウェイマージアルゴリズムとマージされ、そのアルゴリズムへの入力は次のとおりです。

  • 最大共通祖先バージョン
  • 1つのブランチのバージョン
  • 他のブランチのバージョン

  問題ではありません 2つの分岐バージョンが作成されましたか。先祖バージョンから1000回の小さなコミットを使用することも、1回のコミットを使用することもできます。重要なのは、ファイルの最終バージョンです。（はい、これは驚くべきことです！はい、多くのDVCSガイドがこれをひどく間違っています。）

彼はまた、違いについていくつかの良い点を挙げています。

• Subversionには/trunk、たとえばにマージできる「ブードゥー」があります/branches/foo。MercurialとGitはこのモデルを使用しません。代わりに、ブランチは履歴で直接モデル化されます。したがって、履歴は線形ではなく有向非循環グラフになります。これは、Subversionで使用されるモデルよりもはるかに単純なモデルであり、これにより多くのコーナーケースが削減されます。

• マージを簡単に遅らせたり、他の誰かにそれを処理させることさえできます。hg mergeたくさんの競合が発生した場合は、同僚にあなたに頼むことができます。そうすればhg pull、彼はまったく同じ状態になります。ですから、彼はhg mergeあなたよりも対立の解決に優れているかもしれません。

  これは、コミットする前に更新する必要があるSubversionでは非常に困難です。サーバー上の変更を無視して、自分の匿名ブランチでコミットし続けることはできません。一般に、Subversionは、次の場合にダーティな作業コピーで遊ぶことを強制しますsvn update。変更を安全な場所に保存していないため、これは一種の危険です。GitとMercurialでは、最初にコミットしてから、必要に応じて更新およびマージできます。

GitとMercurialがSubversionよりもマージに優れている本当の理由は、実装の問題です。Subversionは、正しい答えが何であるかが明確だと思っても処理できない単純な名前変更の競合があります。MercurialとGitはそれらを簡単に処理します。しかし、Subversionがそれらを同様に処理できなかった理由はありません。集中化されていることは確かに理由ではありません。

中心的な問題は、これらのシステムがバージョン管理されたディレクトリ構造を表す方法にあります。

システム全体が展開するSubversionの基本概念は、バージョン（またはsvn lingoでは「リビジョン」）の概念です：特定の時点でのファイルのスナップショットです。履歴が完全に線形である限り、すべては問題ありませんが、2つの独立した開発ラインからの変更をマージする必要がある場合、svnは両方の現在のバージョンを比較し、最後の共有バージョン間で3者間比較を行う必要がありますそして2つのヘッドバージョン。一方のヘッドで変更されているように見えるが、もう一方のヘッドでは変更されていない行は、簡単に解決できます。両方のヘッドでまったく同じように逸脱するラインはより困難ですが、通常は実行可能です。異なる方法で逸脱する行は、svnに「これを理解できません、人間、これを解決してください」と言っているのです。

対照的に、gitとmercurial は、バージョンではなくチェンジセットを追跡します。リポジトリ全体はチェンジセットのツリーであり、各チェンジセットは親に依存します。親チェンジセットには任意の数の子を含めることができ、ツリールートは空のディレクトリを表します。言い換えると、git / hgは「最初に何もなかった、このパッチが適用され、次にそのパッチなど」と言います。2つの開発ラインをマージする必要がある場合、git / hgは各ヘッドが現在どのように見えるか、最後の共通バージョンがどのように見えるかだけでなく、移行がどのように行われたかを認識し、よりスマートなマージを可能にします。

DVCSでのマージを容易にするもう1つのことは、コミットとプッシュの概念を分離する間接的な結果です。、および同じリポジトリの任意の2つのクローン間のあらゆる種類のクロスマージをいつでも許可します。svnでは、多くの場合、関係のない変更を伴う大きな変更セットをコミットする傾向があります。これは、コミットが中央リポジトリの更新であり、他のすべてのチームメンバーに影響するためです。壊れたバージョンをコミットすると、誰もがあなたに腹を立てます。ほとんどのセットアップにはネットワーク化されたsvnサーバーが関係するため、コミットにはネットワークを介したデータのポンピングも含まれます。つまり、コミットするとワークフローにかなりの遅延が生じます（特に作業コピーが古く、最初にプルする必要がある場合）。gitとmercurialを使用すると、コミットはローカルで行われ、両方ともローカルファイルシステムの処理に非常に効率的であるため、通常は即座に終了します。その結果、人々は（慣れると）少しずつ変更をコミットし、それが機能するようになると、一度に数十件のコミットをプッシュします。その後、マージ時間になると、SCMにはさらに詳細な情報があり、競合を安全かつ自動的に解決する優れたジョブを実行できます。

そして、物事をさらに簡単にする素敵な詳細があります：

• 複数のヘッドを持つことができ、どちらでもコミットできます。Subversionとは異なり、再度コミットする前にプル、更新、マージを組み合わせる必要はありません。マージを選択するまで、複数のヘッドはそのままです。
• ディレクトリは特別に扱われません。代わりに、パスは1つの大きなファイル名と見なされ、すべてのディレクトリは常に同じリビジョンである必要があります。これは、プロジェクトのサブフォルダーが異なるリビジョンにある場合、サブバージョンブードゥーを実行できないことを意味しますが、作業コピーが巨大な管理不能な壊れた混乱になる可能性が低く、さらに興味深いことに、移動は削除として表されません-and-add（レトロフィットメタデータ用でない場合はsvnで完全に壊れます）が、単に名前変更として; ファイルを移動すると、その履歴全体が保持されます。マージは、別のブランチで、移動後に同じファイルの非移動バージョンに対して行われた変更を移動後のファイルに適用することもできます。
• ほとんどの場合、実際には分岐する必要さえありません。代わりに、リポジトリ全体を複製するだけです。クローン作成は安価です。特に同じファイルシステムで行われた場合、クローンを削除したい場合は、クローンが存在するディレクトリを削除するだけです。そのためにhgやgitを使用する必要さえありません。
• マージできるものに関する制限はほとんどありません。同じリポジトリの6つのクローンを作成し、AからB、次にCからB、次にBからD、次にCからD、Bにマージ（または、プッシュまたはプル。明示的なマージは必要ないことが多い）することができます。いつでも、好きなだけ、Aに、DにEに。
• マージしたいリポジトリの1つを複製してから、他のリポジトリにプルすることで、マージをテストできます。必要なことを実行する場合は、実際のターゲットにプッシュバックできますが、そうでない場合は、クローンを破棄して新たに開始します。