ソース管理の使用
アプリケーション開発と RAD の概念 への移動
このトピックでは、いくつものソース管理システムに共通する一般的なソース管理の概念について、概要を説明します。これは自動変更/ソフトウェア構成管理（SCM）システムとも呼ばれるものです。
- メモ： Tools API ユニットには、インターフェイス IOTAProject などのバージョン管理インターフェイスが含まれています。インターフェイス「IOTAVersionControlNotifier」および「IOTAVersionControlServices」も参照してください。Tools API は、VCL とともにインストールされる自己生成ライブラリです。「IDE の拡張」に加えて、コードでの開発者コメントも参照してください。
- メモ： RAD Studio では、複数のバージョン管理システムを使用したバージョン管理機能が提供されています。
- IDE での Subversion Integration では、Subversion 製品を使用した組み込みのバージョン管理機能を提供します。
- IDE での Git Integration では、Git 製品を使用したバージョン管理機能を提供します。
- IDE での Mercurial Integration では、Mercurial 製品を使用したバージョン管理機能を提供します。
ソース管理の基本
ソース管理システムはそれぞれ、1 つ以上の中央リポジトリといくつかのクライアントから構成されます。リポジトリは 1 つのデータベースで、そこには実際のデータ ファイルの他に、ユーザーが定義した各プロジェクトの構造も含まれます。
ほとんどのソース管理システムは、論理プロジェクトという概念を持っていて、その中にファイルを保存します。通常は、1 つまたは複数のツリー型ディレクトリ構造として保存します。1 つのソース管理システム プロジェクトには、1 つまたは複数の RAD Studio プロジェクトと、その他の文書や成果物を含むことができます。また、ソース管理システムでは、独自のユーザー認証を行うこともできますし、ベースとなるオペレーティング システムで提供されている認証を利用することもよくあります。それによって、ソース管理システムで、各ファイルの更新について監査証跡やスナップショットを残すことができます。このスナップショットは、一般に diffs（差分）と呼ばれます。差分だけを保存することで、ソース管理システムは最低限の記憶容量ですべての変更を追跡することができます。ファイルの完全なコピーが必要な場合には、システムは差分をマージして統合したビューを表示します。物理的には、これらの差分は、更新を永続的にマージする準備ができるまで、別々のファイルに格納されます。永続的マージを行うにはコミットのアクションを実行します。
この方法を取ると、他のチーム メンバと並行して作業を進めて、複数の共有プロジェクトのコードを同時に書いた場合にも、あるチーム メンバが行ったコード変更が別のメンバのコード変更を上書きしてしまうことはありません。ソース管理システムは、もっとも基本的な機能として、コードの競合を防ぎ、古いコードがなくならないように保存します。ほとんどのソース管理システムでは、チェックインおよびチェックアウト機能、競合の解決機能、レポート作成機能などを持つ、コード ファイル管理のためのツールが提供されています。ほとんどのシステムには、ロジックの競合解決機能やビルド管理機能は含まれません。お使いのソース管理システムの機能の詳細は、ソース管理システム ベンダから提供されている各製品のマニュアルを参照してください。
一般に、ソース管理システムでは、ソース コード ファイルや HTML 文書、XML 文書といった、テキスト ベースのファイルについてしか、リビジョンの比較やマージをサポートしていません。ソース管理システムによっては、画像ファイルやコンパイル済みコードなどのバイナリ ファイルを、管理下のプロジェクトに含めることが可能です。ただし、バイナリ ファイルのリビジョンの比較やマージはできません。そのようなファイルの特定のリビジョンを保存したり取り出す以上の作業が必要であれば、バイナリ ファイルに対する変更を追跡するための手動システムの作成を検討してください。
リポジトリの基本
ソース管理システムは、ソース ファイルや差分ファイルのコピーを、何らかのデータベース リポジトリに保存します。CVS や VSS など一部のシステムでは、このリポジトリは一連のフラット ファイルとコントロール ファイルで構成される論理構造になっています。他のシステムでは、InterBase、Microsoft Access、MS SQL Server、IBM DB2、Oracleなど、特定のデータベース管理システム（DBMS）をリポジトリとして使用します。
リポジトリは、通常、リモートのサーバーに置かれ、それに対して複数のユーザーが接続し、ファイルのチェックイン、チェックアウトやその他の管理作業を同時に行うことができます。サーバーだけでなく、データベースとも接続できることを確認してください。ネットワーク管理者、システム管理者、データベース管理者に相談して、必要なドライバや接続ソフトウェアと、クライアント側のソース管理ソフトウェアが、自分のマシンにインストールされていることを確認してください。
一部のソース管理システムでは、ローカルにリポジトリを作成し、そこに自分のプロジェクトのスナップショットを持つことができます。時間が経つと、ローカルに持っているプロジェクトとリモートのリポジトリとの間に相違が生じてきます。ローカルのリポジトリからリモートのリポジトリに変更を定期的にマージおよびコミットする方法を規定しておくとよいでしょう。
一般に、共有プロジェクトについてチームの各メンバに別々のリポジトリを持たせるのは、安全だとは言えません。メンバそれぞれが完全に別々のプロジェクトの作業をしていて、各プロジェクトをローカルのソース管理下に置きたい場合には、個別のローカル リポジトリを使うことができます。リモート サーバー上にこれら複数のリポジトリを作成し、サポートやバックアップや保守を集中して行うことも可能です。
プロジェクトの取り扱い
ソース管理システムでは、開発環境と同様に、プロジェクトという概念を使って、関連するファイル群を整理し追跡します。どのソース管理システムを使っている場合でも、ファイルの定義と場所の情報を保持するプロジェクトを作成します。RAD Studio でも、プロジェクトを作成して、あるアプリケーションに関するさまざまなアセンブリやソース コード ファイルをまとめます。RAD Studio は、プロジェクト パラメータをプロジェクト ファイルに保存します。このファイルは、作成したさまざまなコード ファイルと同じように、お使いのソース管理システムのプロジェクトに保存することができます。プロジェクト ファイルをチーム内の開発者全員で共有することも、各自で自分のプロジェクト ファイルを保持することも可能です。
ほとんどのソース管理システムでは、実際にバイナリ ファイルなのかどうかに関わらず、開発環境のプロジェクト ファイルをバイナリ ファイルとして扱います。その結果、プロジェクト ファイルをソース管理システムのリポジトリにチェックインすると、ソース管理システムは、変更のマージを行うことなく、旧バージョンのファイルを新バージョンで上書きします。これは、プロジェクトを取得するときやプロジェクト ファイルをチェックアウトする場合にも同様で、マージすることなく新バージョンのプロジェクト ファイルによって旧バージョンが上書きされます。
ファイルの取り扱い
ファイルは、ソース管理システムで管理することのできるもっとも低いレベルのオブジェクトです。ソース管理下に置きたいコードは、ファイルに含めなければなりません。ほとんどのソース管理システムでは、ファイルを論理ツリー構造に格納します。CVS など一部のシステムでは、ディレクトリ レベルを指すのに、実際に枝などの用語を使っています。RAD Studio プロジェクト内にファイルを作成してソース管理システムに追加することも、ソース管理システムから既存のファイルを取得することも可能です。ソース管理システムにディレクトリ全体を追加し、それから個々のファイルや複数のファイルやサブディレクトリ ツリー全体をチェックアウトすることができます。RAD Studio では、2 つのレベルでファイルを管理することができます。つまり、RAD Studio 内のプロジェクト レベルとソース管理システム内のプロジェクト レベル（ソース管理システムに対する RAD Studio インターフェイス経由で）です。
メモ： ［履歴］ビューには、ローカルのソース ファイルのリビジョン情報が表示されます。［履歴］ビューを使うと、デザイナやコード エディタでファイルに対して行った変更を追跡することができます。