SubversionとCVS
SVNとCVSの両方を少し使用しましたが、開始する新しいプロジェクトにはどちらかを選択する必要があります。
両方を広範囲に使用した人は、長所と短所を提供してください。最高の学習リソースもありがたいです。
これは小規模なプロジェクトで、1〜2人の開発者が開始するだけです。
私は両方を使用しました。比較はありません。あなたはsvnが欲しいです。 CVSを使用する唯一の理由は、現状を変更したくない管理者がいるレガシーシステムを入力または引き継ぐためです。新しいプロジェクトを開始する場合、CVSがSubversionよりも優れていると主張することは事実上不可能です。
グーグルで検索すると、CVSでSubversionを使用するための多くの比較と理論的根拠を見つけることができます。 CVSに対するSubversionの利点のいくつか：
- ファイルやディレクトリをきれいに移動または名前変更できます
- アトミックコミット
- 「安い」コピーと分岐
- コミットは（個々のファイルの履歴だけでなく）ツリー全体の変更セットです
以上のことをすべて言ったので、Bazaar、Mercurial、gitなどの分散VCSのいくつかも検討することをお勧めします。私はすべてのプロジェクトで個人的にgitを使用しています。
Subversionは、CVSに対していくつかの大きな勝利を収めています。
- 優れたリモートオプションhttp/https/svn vs pserver
- アトミックコミット
- ユビキタスツールのサポート
- リネーム
- ディレクトリのバージョン管理
ただし、重大な欠点があります。一番大きいのは、ブランチとタグがsvnのファーストクラスの市民ではなく、規約に準拠した単なるディレクトリであることです。実際の分岐とタグ付け（他のコメントで言及）の利点のいくつかを失うことに加えて、それが作成する最大の問題は、それが非常に簡単に台無しにすることです。
Subversionが設定ではなく規約を使用するということは、リポジトリの構造を事前に考え、全員がそれを順守することを保証する必要があることを意味します。それ以外の場合は、レポを変更する必要があるツールはもちろん、将来の世代のために傷の世界を作成します。
1.5より前では、マージとミラーリングはほとんど存在しませんでした（十分な支援）。 1.5はこれらの両方に対処するための措置を講じましたが、まだ改善の余地があります。 Subversionでのマージは、必要以上に困難です。
SVNを介したSVNはほとんど簡単です。ただし、DVCSが提供しなければならないもの（Git、Hg、Bzr）を少なくとも考慮しないことや、予算により、評判の良い商用ツール（Accurev、Perforce）が許容される場合、あなたは逃します。
Subversionはおそらく正しい選択ですが、最良の結果を得るには宿題をしなければなりません。レッドブックから始める http://svnbook.red-bean.com/
ほとんどの場合、CVSではなくSubversionを選択しますが、Subversionで何が欠けているかを知っておく必要があります。
CVSはタグとブランチを異なるものと見なします。 Subversionはサポートしていません。これは、Subversionの上に構築されたサードパーティツール（ソース管理統合を備えたIDEなど）が、その違いを把握するのが難しいということを意味します。通常、タグとブランチの場所を伝えるために特別な構成を行う必要があります。また、ユーザーが特定のファイルシステムレイアウトを使用することを確認する必要があります。
Subversionはファイルを見て、誰かがそれからブランチまたはタグを作成したポイントを伝えることができません。 CVSGraphなどのツールは、この情報を使用してファイルの履歴のツリーを描画できます。 Subversionでこれを行うには、すべてのbranch/tagsディレクトリを検索する必要がありますが、これをうまく行うツールは見たことがありません。
私の経験では、CVSはずっと長く、サードパーティのツールはより安定しています。
私は昔ながらの電話をしますが、私はCVSでの分岐/タグ付けモデルを好みました。
CVSでは、ブランチとタグは異なりますthings。タグは、リビジョンのラベルです。これらは、Webサーバーに同期するファイルの[〜＃〜] production [〜＃〜]タグのマーク付けなどに非常に役立ちます。 [〜＃〜] production [〜＃〜]ファイルを更新するためにマージする必要はありません。タグを移動するだけです。
ブランチはメインファイルと同じ「名前空間」に存在します。特定のファイルのすべてのmodを追跡するのは簡単です。
SVNには、タグのようなものはありません。枝だけがあります。タグが必要な場合は、ブランチを作成して、タグのふりをする必要があります。ブランチは基本的にファイルのコピーです。前回ブランチ/マージにSVNを使用したときに、マージして元に戻したい場合は、事前ブランチファイルのリビジョンを記録する必要がありました（SVNの専門家ではないため、これは変更されている可能性があります）。
そうは言っても、SVNは他のあらゆる点で優れていると思います。おそらく、CVSで新しいプロジェクトを開始すべきではないでしょう。
これに対する多くの答えを得るでしょう、私は疑います。彼らも皆同意するかもしれません。
これら2つの選択肢の間で、Subversionを使用する必要があることは間違いないと思います。 Subversionは「より良いCVS」として構築されたため、もはやCVSを積極的に保守する人はいません。 Subversionには、履歴を失うことなくファイルの名前を変更して移動する機能があり、アトミックコミットをサポートし、より堅牢なリポジトリ形式を持ち、最新のアクセス方法を持ち、サードパーティツールのサポートが優れています。
Subversionは「より良いCVS」のようなものです。ファイルとディレクトリの移動をうまく処理します。分散型VCSには劣りますが、分岐サポートがあります。
Git、Bazaar、Mercurialなどの分散VCSの使用を検討することもできます。
編集：これは 同様の質問へのリンク です
一般にSubversion ..ただし、リソースの問題に注意する必要があります。
私がゲーム会社で働いていたとき、数百の小さなファイルを含むいくつかのディレクトリと、数百のMegファイルを含む他のディレクトリがありました。 CVSからSubversionに切り替えたとき、レポのチェックアウトの速度は1時間から4または5時間に低下しました。更新も大幅に遅くなりました。
これはほぼ確実に、ネイティブのcsv pserverと比較して、httpまたはsshのいずれかを使用してファイルデータを送信することによるものです。ただし、ネイティブsvnプロトコルを使用することができ、これにより問題が軽減されるはずです。これは私の古い会社ではテストしていません。
しばしば無視される別の問題はストレージスペースです。SubversionはローカルでCVSの数倍のストレージを使用していることがわかりました。レポデータのローカルコピーを保存して差分を高速化することを思い出すようですが、リポジトリに数ギガバイトを保存しない限り、これは大きな問題にはなりません。
私は3.5年間Subversionを使用してきましたが、現在はソース管理にCVSを使用している他の会社に移りました。最初は、この2つの間に多くの違いはありませんが、マージ操作（これが私の最大の懸念事項です）に来ると、CVSがより良い仕事をしたと言えます。 SVNのブランチ/タグの概念はわかりにくいですが、CVSでは非常に明確です。また、マージ（私の場合、ブランチの統合）はSVNよりもCVSの方がはるかに簡単です。これまでのところ、CVSの弱点は、アトミックコミットのみです。そうでなければ、それは良い選択でしょう。