SVNはGitよりも優れていますか？[閉まっている]

プログラマーツールをめぐる議論の大半は、個人的な選択（ユーザーによる）またはデザイン重視、つまり特定のユースケースに応じたデザインの最適化（ツールビルダーによる）に留まることは間違いありません。テキストエディターはおそらく最も有名な例です-職場ではWindowsで動作し、自宅ではMacでHaskellでコードを作成するコーダー、クロスプラットフォームおよびコンパイラー統合を重視するため、TextMateではなくEmacsを選択します。

新しく導入された技術が、現存するオプションよりも明らかに優れていることはあまりありません。

これは実際、バージョン管理システム（VCS）、特に集中型 VCS（CVSおよびSVN）対分散 VCS（GitおよびMercurial）の場合ですか？

SVNを約5年間使用しましたが、現在、SVNは私が働いている場所で使用されています。3年弱前、すべての個人プロジェクトでGit（およびGitHub）に切り替えました。

Subversionに対するGitの多くの利点（および集中型VCS上の分散の利点の大部分を抽象化する）を考えることはできますが、1つの逆の例、つまり関連するタスクと通常のプログラマーで生じるいくつかのタスクを考えることはできませんワークフロー）そのSubversionはGitよりも優れています。

だけではないGitが優れていること、など-私はこのことから描いた結論は、私がどのようなデータを持っていないということです

私の推測では、そのような反例が存在するため、この質問です。

Subversionは中央リポジトリです

多くの人は、速度と複数のコピーの明らかな利点のためにリポジトリを分散したいと思うでしょうが、中央リポジトリがより望ましい状況があります。たとえば、誰かにアクセスさせたくない重要なコードがある場合は、おそらくGitの下に配置したくないでしょう。多くの企業はコードを集中管理したいと考えており、すべての（深刻な）政府プロジェクトは中央リポジトリの下にあります。

Subversionは従来の知恵です

これは、多くの人々（特にマネージャーとボス）がバージョンに番号を付け、開発を彼らの脳にハードコードされた時間に沿った「単一行」として見る通常の方法を持っていると言うことです。攻撃はありませんが、Gitの自由は飲み込むのが簡単ではありません。Gitブックの最初の章では、従来の理想をすべて頭から消して、新たに始めることを説明しています。

Subversionは一方向でそれを行いますが、それ以外は何もしません

SVNはバージョン管理システムです。仕事をする方法が1つあり、誰もが同じ方法で行います。期間。これにより、他の集中型VCSからのSVNへ/からの移行が容易になります。Gitは純粋なVCSでさえありません-ファイルシステムであり、さまざまな状況でリポジトリを設定するための多くのトポロジーを備えています-そして標準はありません。そのため、いずれかを選択するのが難しくなります。

その他の利点は次のとおりです。

• SVNは空のディレクトリをサポートします
• SVNのWindowsサポートが改善されました
• SVNはサブツリーをチェックアウト/クローンできます
• SVNはsvn lock、マージが困難なファイルに役立つ排他的アクセス制御をサポートしています
• SVNはバイナリファイルと大きなファイルをより簡単にサポートします（古いバージョンをどこにでもコピーする必要はありません）。
• プル/プッシュはなく、ローカルの変更は常に暗黙的にリベースされるため、コミットの追加に必要なステップはかなり少なくなりますsvn update。

Gitに対するSubversionの利点の1つは、Subversionがサブツリーのみをチェックアウトできることです。Gitを使用すると、リポジトリ全体がユニットになり、すべてを取得することも、まったく取得することもできません。モジュラーコードを使用すると、Gitサブモジュールと比較して非常に便利です。（Gitサブモジュールにも当然の位置がありますが。）

そして小さな小さな利点：Subversionは空のディレクトリを追跡できます。Gitはファイルの内容を追跡するため、ファイルのないディレクトリは表示されません。

私は3つ考えることができます。第一に、特に開発者以外にとっては、理解するのがかなり簡単です。概念的には、DCVSオプションよりもはるかに簡単です。2つ目は成熟度、特にWindows上のTortoiseSVNです。しかし、TortoiseHgは急速に追いついています。第三に、獣の性質-ツリーの任意のレベルから物事をチェックできるファイルシステムのイメージ-は、いくつかのシナリオで非常に便利になることがあります-さまざまな構成ファイルのバージョン管理など数十のリポジトリのないサーバー。

これは、すべての開発をMercurialに移行していないという意味ではありません。

• SVNリポジトリは、管理者および管理者の観点から管理しやすくなっています（ACL +認証方法+ホットコピー+ミラー+ダンプ）
• SVN *フックは実装とサポートが簡単です
• svn:external サブモジュールよりも強力で柔軟性がある
• ファイルシステムベースのリポジトリツリーは、論理のみの分離を備えたモノリシックリポジトリよりも使いやすい
• SVNにはさらに異なるクライアントツールがあります
• SVNにはサードパーティ製の使用可能なWebフロントエンドがあり、Gitのものよりはるかに優れています
• SVNはあなたの脳を破壊しません

私はこれを他の誰かの答えに対するコメントとして書いたが、それ自体が答えになるに値すると思う。

私の会社のSVNの慎重に選択された構成では、コンテンツを編集するためにファイルレベルのロックが必要であり、マージを使用することはありません。その結果、複数の開発者がロックをめぐって競合し、それが大きなボトルネックになる可能性があり、マージ競合の可能性はありません。

SVNは間違いなくGitよりもトップダウンの管理制御を行います。Gitへのskunkworksの移行（許可ではなく許しを求めています）で、すべてのスレーブであるソフトウェアで強制される中央マスター制御サーバーは存在しないという考えで、マネージャーを何度も怖がらせてきました。

私の理由：

• 成熟度-サーバーとツール（TortoiseSVNなど）の両方
• シンプルさ-関与するステップが少なく、コミットはコミットです。GitやMercurialなどのDVCSでは、コミットしてからプッシュします。
• バイナリ処理-SVNは、バイナリ実行可能ファイルとイメージをGit / Hgよりも適切に処理します。ビルド関連のツールをソース管理にチェックインしたいので、特に.NETプロジェクトで役立ちます。
• 番号付け-SVNには、数字だけを使用した読み取り可能なコミット番号付けスキームがあり、リビジョン番号を追跡しやすくなっています。GitとHgはこれをまったく異なった方法で行います。

良い情報を探していることを感謝しますが、この種の質問は「Gitは非常に勝っていると思うし、sxor zeh suxorz！」答えます。

私が試したところ、個人的にはGitが私の小さなチームにとって少し多すぎることに気づきました。地理的に分散している大規模な分散チームまたはチームのグループに最適だと思われました。私はGitの利点を大いに理解していますが、私の意見ではソース管理は私を夜中に追いやるものではありません。

私はシカハンターで、私と私の友人たちは外に出ると歯に武装しており、弾薬とハイテクギアでいっぱいです。私は、単一のライフル、7つの弾丸、およびバックナイフで現れます。7ラウンド以上必要な場合は、何か間違ったことをしています。他の人と同じようにしています。

私がやろうとしているのは、あなたが中小規模のプロジェクトに取り組んでいる小さなチームで、すでにSVNに慣れているならそれを使うということです。確かにCVSや（震え）SourceSafeよりも優れており、リポジトリをセットアップするのに5分もかかりません。Gitは時々やり過ぎになることがあります。

これはすべて相対的なものであり、maple_shaftが言ったように、あなたのために働くなら、変更しないでください！

しかし、本当に何かが必要な場合は、デザイナーやWebプログラマーなどに適していると思います。画像やバイナリファイルの処理が少し改善されています。

使いやすさ。これは、実際にはSubversionのメリットではなく、TortoiseSVNのメリットです。TortoiseGitは存在しますが、TortoiseSVNに対応するにはまだ長い道のりがあります。

GitがSVNよりも優れている点を尋ねられた場合は、GitHubと返信します。サードパーティ製のツールがどのように大きな違いをもたらすかはおもしろいです。

あなたはときに分岐し、マージする必要はありません（と、SVNをTortoiseSVNは Windows上で）理解し、非常に使いやすいです。Gitは分岐/マージを簡単にしようとするため、単純な場合には非常に複雑です。

（小規模なプロジェクトの多くは、うまく管理されていれば分岐する必要はありません。Gitは複雑なケースを対象としているため、ほとんどのGitドキュメントでは、分岐やマージなどの複雑な操作が必要です。）

おじいちゃんはWindows XPコンピューターでSVNを使用できましたが、Gitの使用に問題がありました。たぶん、これはTortoiseGitよりもTortoiseSVNの成果かもしれませんが、Gitが本質的に強力で、したがってより複雑であるという事実に結びついていると思います。

おじいちゃんにとっては、最近はプログラミングをしていないので、今ではそれほど問題ではありません。しかし、私はかつてチームにいて、グラフィックアーティストもソース管理を使用していました。

そして、彼らは単に自分のツールが機能することを期待しているので（私もそうですが、失敗した場合に機能させるための現実的なチャンスがあります）、直感的です。事実とは別に、彼らにDVCSを理解させるのはかなりの努力でしたが、得られるものはほとんどありませんでした。また、チームにプログラマが2人しかいないので、SVNだけに固執するのも理にかなっています。

職場では、次の2つの理由により、開発者をSVNからDVCSに切り替えることができませんでした。

• 部分的なチェックアウト（プロジェクトツリーの異なる深さからの3つのフォルダーのみ）
• ファイルのロック（バイナリ形式のレポート）

• 「svn commit」を実行するときの安心感。コミットはサーバーに送信されるため、変更がコミットされた後に消去される可能性があることはありません。gitでは、コミットはローカルであるため、プッシュするまで、「rm -rf」が外れてしまいます。
• コミットが認証されます。gitのデフォルトでは、私は誰としてもコミットしていると伝えることができます。
• 日常使用のために学習するコマンドが少なくなります。「svn checkout」、「svn up」、および「svn commit」を使用すると、かなり遠くまで移動できます。
• 共有チェックアウトの方がずっと便利です。コミットすると、ユーザー名/パスワードが要求されます。特定のコマンドライン引数を渡すことを覚えておく必要はありません。職場では、プロジェクトの共有svnチェックアウトを備えた共有マシンがある場合があります。誰かが「ボブはこのマシンでこれを見ることができますか」と言うかもしれませんし、彼はそうすることができます。
• リポジトリのレイアウト。アンブレラプロジェクトとサブプロジェクトを作成し、いつチェックアウトするかを選択できます。
• リビジョン番号は増加する整数です。
• 中央リポジトリのワークフロー用に設計されています。

他の人がかなり良い答えを投稿しましたが、許可はどうですか？SSH上のSubversionを使用して、SVN用にサーバー上に別のアカウントを作成できます。異なる開発者は、リポジトリの異なる部分への異なるアクセス権を付与できます。GITでできますか？ギトライトはあると思いますが、それは私には柔軟性や堅牢性がないように見えますし、実際にそれを使用している人を知りません。

速度。大きなgitリポジトリのクローン作成に10〜15分かかる場合がありますが、同様のサイズのSubversionリポジトリはチェックアウトに数分かかります。

これをコメントではなく、回答として投稿します。

DVCSが現在流行していることは認めますが、その理由を説明します。

DVCSの方が優れているのは、多くの人が「これが最初から取り組むべき方法だ」と言っているからです。確かに、SVNで使用していたDVCSを使用して、SVNを廃止することができます。

ただし、すべてのソフトウェアプロジェクトが次のように優れているわけではありません。

• 長期プロジェクトは、DVCSから多くの恩恵を受けています。オーバーヘッドが少なく、管理（分岐など）がはるかに優れており、googleコードやgithubなどのホストで大幅にサポートされているためです。

• これらのプロジェクトは唯一のものではありません。外部の世界やインターネットからの支援なしに企業で開発されている他の種類のプロジェクトがあります。すべてが社内で、そして多くの場合短期的に行われます。良い例：ビデオゲーム。コードは急速に進化しています。

後者の場合、開発者はDVCSが提供できる分岐機能や高度な機能を実際に必要とせず、ソースコードとアセットを共有したいだけです。期限があるため、彼らが作成したコードは再利用されそうにありません。いくつかの理由により、DVCSではなくSVNに依存しています。

• 開発者には会社に属するマシンがあり、これは急速に変わる可能性があります。リポジトリの設定は時間の損失です。
• それらの人が自分のマシンを持っていない場合、彼らは同じソースコード/プロジェクトの一部で作業している可能性が低くなります。さらに、集中データ用に1つ。
• ネットワーク速度と大金により、すべてのSVNを処理する集中型サーバーを使用できます。これは悪い習慣ですが、バックアップが作成されるなどです。
• SVNは間違った方法であっても使用が簡単です。冗長性のないピア上のファイルの同期は簡単な問題ではありません。

ゲーム業界のマシンとSVNが時間を節約する方法について考えてください。ゲームは反復プログラミングとアダプティブコードに関するものであるため、人々はこれらのプロジェクトでより多くのコミュニケーションを取ります。コーディングするのは難しいことではありませんが、できるだけ早く正しい方法で行う必要があります。プログラマーは雇われ、彼らの部分をコーディングし、それをコンパイルし、少しテストし、コミットし、完了し、ゲームテスターが残りを処理します。

DVCSは、インターネット用および非常に複雑なプロジェクト用に作成されています。SVNは、小規模で短期のタイトなチームプロジェクト向けです。SVNから多くを学ぶ必要はありません、それはほとんどdiffのないFTPです。

SubversionとGitはどちらも、開発とコラボレーションに対する特定の（そして非常に異なる）アプローチを奨励しています。組織や文化に応じて、Gitからより多くの利益を得る組織とSubversionからより多くの利益を得る組織があります。

GitとMercurialはどちらも、非常に有能なプロのプログラマーの分散された、ゆるく編成されたチームに最適です。これらの人気のあるDVCSツールはどちらも小さなリポジトリを推奨し、開発者間の再利用は（比較的）安定したインターフェイスを備えた公開ライブラリを介して行われます。

一方、Subversionは、開発者間のコミュニケーションを増やし、日々の開発活動に対する組織の制御を強化することで、より集中化され、緊密に結合された管理構造を促進します。これらのよりコンパクトに編成されたチーム内では、開発者間の再利用は、（比較的）不安定なインターフェイスを備えた未公開ライブラリを介して行われる傾向があります。TortoiseSVNでは、Subversionが、プロのプログラマーではないメンバー（システムエンジニア、アルゴリズムエンジニア、またはその他の分野の専門家など）を持つ学際的なチームをサポートすることもできます。

チームが分散していて、メンバーが自宅または多くの異なる国際サイトから作業している場合、または彼らが単独で黙って仕事をしたい場合、対面のコミュニケーションがほとんどない場合は、GitやMercurialのようなDVCSが良いでしょう文化的適合。

一方、あなたのチームが単一のサイトに配置されており、開発への積極的な「チーム」アプローチと多くの対面コミュニケーションがあり、空中に「バズ」がある場合、SVNは学際的なチームが多い場合は特に、文化的適合性が向上します。

もちろん、GitとHg（パワフルで柔軟な）を構成して、お望みのことを何でも行うことができますが、それは間違いなくより多くの作業であり、特にチームのメンバーにとっては使いにくいです当然、いかなる形式のバージョン管理も使用しません。

最後に、Svnで「ホット」ライブラリ開発を使用した共有機能（CIおよびテスト駆動アプローチ）を使用すると、より分散された疎結合チームでは達成が困難な協調開発が可能になります。

以下は、私がまだSVNにとどまっている2つの理由です。

1. 学習曲線。SVNは、セットアップ（サーバーまたはクライアントも）、使いやすさ、およびコマンドでさえ、Gitよりも簡単です。
2. Subversion Edge、VisualSVN、uberSVNなどのより良いサーバーパッケージ

現在、バージョン管理には2つの主要な傾向があります。配布および統合。

Gitは分散化に優れています。

SVNには、SVNと統合する多くのツールが組み込まれています。SVNサーバーをセットアップして、修正をチェックインするときに、チェックインコメントにバグ番号を記載し、自動的にそれを「テスト中」状態に設定し、割り当てられたテスターに​​必要なことを警告するように設定するのが一般的ですそれを見てください。次に、リリースにタグを付けて、このリリースで修正されたすべてのバグのリストを取得できます。

SVNでこれを行うツールは成熟しており、毎日使用されています。

Subversionでは、コミットが完了してプッシュされた後、ログメッセージ（「コミットメッセージ」とも呼ばれます）を編集できます。最も実用的な用途では、これはgitを含む分散システムの設計では不可能です。もちろん、gitでは「git commit --amend」を実行できますが、コミットが他の場所にプッシュされた後は役に立ちません。SVNでは、ログメッセージを編集するときは、全員が共有する中央リポジトリで実行するため、全員が編集を取得でき、リビジョンの識別子は変更されません。

多くの場合、事後のログメッセージの編集は非常に便利です。ログメッセージの間違いや省略を修正するだけでなく、ログメッセージを更新して将来のコミット（バグを修正するリビジョンや現在のリビジョンで導入された作業を完了するリビジョンなど）を参照することなどができます。。

ちなみに、情報を失う危険はありません。pre-revprop-changeフックとpost-revprop-changeフックを使用すると、本当に心配な場合は古いメッセージの履歴を保存したり、ログメッセージの差分（これは実際に一般的です）監査証跡。