最近、私の新しい仕事で、私の部門（私たちは主に株と競馬のウェブサイトを構築していて、オフィスでウェブサイトに取り組んでいます）はSVNまたはMercurialの使用を検討しています。私たちのプロジェクト マネージャーは、SVN を支持すると言います (理由は教えてくれませんでした) が、Mercurial を選択する選択肢も与えてくれ、私たちの意見を求めました (最終的な決定はまだ彼にあります)。
オンラインのほとんどの記事は、SVN (または同様のもの) ではなく Mercurial を選択する理由を説明するものです。逆に聞きたい。
では、SVN よりも Mercurial/Git の方が多くの利点があるにもかかわらず、新しいプロジェクトで Mercurial よりも SVN を選択するのはいつ、どのような理由でしょうか?
同僚や経営陣の世論によってやむを得ない場合。それが最も可能性の高いシナリオです。
Mercurial ではなく Subversion または Perforce を選択する特定の状況がいくつかあります。それらは非常に具体的な機能に関係しています。たとえば、ランダムなサブディレクトリを独自のリポジトリとして扱う機能は、状況によっては便利です。チェックアウト時にディレクトリ構造を再配置する Perforce の機能も役立ちます。また、Perforce は、ゲーム開発やその他の種類のメディア作業で使用される大きなバイナリ オブジェクトの処理においても優れた仕事をしていますが、現在のところ、Mercurial も Git もこれらの処理を特に得意としていません。
しかし、一般的に、非分散型のリビジョン管理システムを自分で選択する理由は他にありません。それらが非常に制限的で制約的であることがわかります。バージョン管理とは何かを知って以来、私は彼らに失望してきました。純粋なワークフローの観点から、集中型のリビジョン管理システムで実現でき、分散型のリビジョン管理システムで実現できないものはありません。
Subversion は、非常に優れた集中型バージョン管理システムです。これは成熟しており、Trac などの他のツールによって十分にサポートされています。その「スナップショットごとに 1 つのバージョン」は際立っており、「ブランチ」は単に「軽いコピー」にすぎません。本当に、より「脆弱な」セマンティクス (ファイルごとのバージョン番号や独自の特異性など) を伴う従来のバージョン管理のコンテキストでは、Subversion は際立っています。（何年も使っています。）
とは言っても、私は Mercurial に移行しています。(私は Git を検討しますが、現在 Windows では Mercurial の方がはるかに成熟しています。) Tortoise-Hg は Tortoise-SVN ほど成熟していません。ただし、Mercurial と Git はどちらも BUILT TO MERGE です。そして、これがバージョン管理システムの根本的な問題です。
Mercurial では、すべてのリポジトリにすべてが含まれています。マージは簡単です。リポジトリはそれ自体が「サンドボックス」であるため、「トランク」や「ブランチ」の「千里眼」を持っている必要はなく、その他のブランチ前の計画を立てる必要はありません。要するに、分散リポジトリは、開発者がコマンド構造 (「最終的に承認されたトランク」ブランチに移動) に集中している場合でも、開発者のチームが機能する方法です。
概要: Subversion は優れたモデルですが、非常に集中化されています。成熟したツールで成熟しており、他のツール (Trac など) との統合も成熟しています。Mercurial (および Git) はより優れたモデルですが、Subversion と同じ「リポジトリごとの単一バージョンのスナップショット」を提供します。ツール (Tortoise-Hg など) は成熟度が低く (Trac との統合はより手間がかかります)、Mercurial を使用する場合 (同期された分散リポジトリなど) は少し異なる考え方になるため、いくつかの利点がありますが、実際には問題を別の方法で考えてください (Subversion の場合とは異なります)。
私は毎日両方を使用しています。彼らは両方とも素晴らしいです。Mercurial と Trac の統合がより成熟した方法で実現したら、完全に Mercurial に移行します。(成熟度の低い Tortoise-Hg は Tortoise-Svn ほど良くはありませんが、私はそれと一緒に暮らすことができます。)
Mercurial のみへの完全な移行には、しばらく時間がかかる場合があります (Trac がネイティブの Mercurial 統合を提供するため、1 年または 2 年以上かかります)。Mercurial と Subversion の間のインポート/エクスポートはひどいものではありません。既存のコード ベースでは両方を使用します。中央の「トランク」は Subversion であり、ローカルの変更は Mercurial で行われ、最終的に Subversion にチェックインされます。できます。
他のツールと組み合わせる場合は、Subversion および Mercurial とのインターフェイスを確認してください。すべてが等しい場合は、Mercurial に進みます。それ以外の場合は、Subversion で問題が発生することはありません (特に Trac によるサポートのために Subversion を使用しています)。その上で Mercurial を使用しても問題ありません (使用しています)。
最後に、質問をどのように組み立てたかという文脈で：
では、SVN よりも Mercurial/Git の方が多くの利点があるにもかかわらず、新しいプロジェクトで Mercurial よりも SVN を選択するのはいつ、どのような理由でしょうか?
私は Mercurial よりも Svn を選びます:
一言: TortoiseSVN。私にとって、TortoiseSVN はあらゆる VCS のすべての GUI クライアントの標準です。SVN には DVCS の欠点がありますが、TortoiseSVN は SVN を簡単に使用できるようにします。TortoiseGit はかなり優れており、TortoiseSVN をモデル化していますが、TortoiseHg はそれほど優れていません。
もう 1 つの理由は、優れたシステム管理者のサポートです。SVNに関して言えば、ツールは十分に開発され、成熟しています。Git と Hg はまだ追いついていません。
ここで私の答えを見ることもできます:どのバージョン管理が私に最も適していますか?
また、これは非常によく似た質問です: https://stackoverflow.com/questions/2693045/mercurial-vs-subversion
Mercurialの利点が利点ではない場合は、状況に応じて使用または適用します。