William のコメントが示すように、RCS は単一のファイルでのみ機能します。(また、マルチユーザーのものには特に適していないようです。)
もちろん、各 (ソース) ファイルを RCS の管理下にあるディレクトリに置くことを妨げるものは何もありません。実際、これは基本的に CVS が行うことです (ただし、最近のバージョンでは、以前のように RCS を呼び出してそれを行うのではなく、RCS データ自体を処理します)。残念ながら、これにより変更履歴がかなり断片化されます。多くのファイルに影響を与えるコミットは、たまたま同じコミット メッセージ (およびタイムスタンプ) を持つ各ファイルへの個別のコミットとして終了します。 「同じ」リビジョン。foo
(これにより、タグは非常に重要になります。) CVS には、コミットの原子性に関する問題もあります。ファイルではコミット A がコミット B に先行するが、ファイルではbar
コミット B がコミットA に先行するなど、コミット A とコミット B が絡み合うことになる可能性があります。 !
SVN (Subversion) は、CVS の問題の一部を修正する試みですが、いくつかの新しい制限ももたらし、既存の問題の多くを維持しています。複数ファイルのプロジェクトには分散バージョン管理システム (DVCS) を使用する方がおそらく (William が暗示しているように) 賢明です。多くの選択肢があります:
- Darcsは独自のパッチ ベース モデルを使用します。リポジトリは一連のパッチとして扱われ、空のツリーに適用して現在のリビジョンを構築できます。多くの場合、パッチのペアを「交換」することでパッチを並べ替えることができ、他のリポジトリからパッチをチェリーピッキングするのは非常に簡単です。欠点は、変更履歴がほとんどの DVCS よりも少し明確でないことです。http://wiki.darcs.net/Using/Model、http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theoryを参照 してください。
- 有向非巡回グラフ (DAG) ベースの DVCS は、レポジトリをリビジョンの有向非巡回グラフとしてモデル化し、各リビジョンは 1 つ、2 つ、またはそれ以上の親を持つことができます。各リビジョンには、ファイル ツリーの状態が関連付けられています。名前の変更も何らかの形で追跡されることがあります。
- Git、すでに述べたように。非常に単純なモデルを持っていますが、非常に複雑なインターフェースを持っています: 多くのコマンドがあり、そのうちのいくつかは実際には人間が使用することを意図していません (その多くの部分がシェル スクリプトでプロトタイプ化されているため)。あなたが欲しいものを見つけるために。また、そのモデルは少し単純すぎるかもしれません。名前の変更をまったく追跡しません。
- Bazaar (別名
bzr
) には、ファイル/ディレクトリの名前変更のサポートを含む、より複雑なモデルがあります。ただし、どのようなドキュメントが存在するとしても、Git ほどアクセスしやすいわけではないため、どれだけ複雑かを言うのは困難です。ただし、ユーザー インターフェイスはかなりシンプルであり、分散開発に適した SVN プラグインを含む多くの便利なプラグインがあります。ブランチ、および bzr メタデータは SVN にコミットされます。コミット アクセス権を持たずに SVN ベースのプロジェクトでハッキングを開始したいが、最終的には変更をコミットすることを望んでいる場合は、問題が大幅に軽減されます。Bazaar は、個人的にお気に入りの DAG ベースの DVCS です。
- Mercurial (aka
hg
) は Bazaar にかなり似ているように見えますが、ディレクトリではなく個々のファイルの名前変更のみを追跡すると思います。SVN プラグインは Bazaar のものほど優れていませんが、プラグインもサポートしています。ロスレス コミットをサポートしていないため、他の人のブランチから分岐するのは賢明ではありません。あまり経験がないので、深く評価することはできません。