レベル: 初級 M. Tim Jones, Consultant Engineer, Emulex
2006年 10月 10日 バージョン・コントロール・システム、またはソース管理システムは、最近のソフトウェア開発にとって非常に重要です。これを使わないと、まるでスピードを出しすぎて車を運転するような羽目になります。つまり、楽しく、早く目的地に着けるかもしれませんが、事故は避けられません。この記事では、CVS や Subversion、Arch、Git などを含めた SCM (Software Configuration Management) システムとその利点について、概要を説明します。また、一般的な SCM のアーキテクチャーについても解説します。そして最後に、新しい手法にはどんなものがあるか、従来のものとの違いについて説明します。(編集者より: Git の構文が改善されたのを反映して、リスト 4 を更新しました。)
SCM (Software Configuration Management) とは何か
皆さんがおそらく学校では習わなかったツールの中で、SCM は最も重要なものの 1 つです。ソフトウェア (またはソース) コントロールは、その名前のとおり、ソースコードと時間の経過によるソースコードの進化を維持管理するためのツールと、それに関連するプロセスを言います。SCM の主な機能は、次のようなものです。
- リポジトリーの中のファイルを維持管理する
- リポジトリーの中のファイルのリビジョンを維持管理する
- 複数の開発者がいる環境でソース変更の競合を検出し、マージを実現する
- 変更を行った人を追跡する
- 一貫性のある反復可能なビルドのために、ファイルの構成管理 (リビジョンの関連付け) を行う
 |
SCM の応用対象
通常、ソース・コントロールと言うとソースコードと関連ファイルのコントロールを指しますが、ソース管理はあらゆるタイプの資産に適用することができます。HTML (Hypertext Markup Language) とバイナリーの画像ファイル、一般的なテキスト文書、その他任意のファイルから構成される Web サイトは、SCM システムによるリビジョン・コントロールの対象となることができます。
|
|
つまり SCM によって、リポジトリーの中にある一連のファイルをコントロールでき、また、こうしたファイルのリビジョンを追跡することができます。ある別の開発者がリポジトリーの中のファイルに変更を加えると、SCM は変更の競合を見つけ出し、それらを自動的にマージするか、あるいは競合があることを通知します。この機能があると、複数の開発者が同じ一連のファイルを変更できるため、重要な機能です。また、SCM では、誰がどの変更を行ったのかを追跡することができます。そして最後に、SCM を使うことによって、ソフトウェア・イメージまたは実行可能ファイルなどを構成するソースファイル群を、相互に関連したファイル・セットとして論理的にグループ分けすることができます。
SCM の用語
SCM のアーキテクチャーの詳細やタイプについて学ぶ前に、まず SCM の用語を学ぶ必要があります。まず、リポジトリーという言葉があります。リポジトリーは、ファイルを保存し、管理するための中心となる場所です (ツリーと呼ばれることもあります)。リポジトリーからファイルを取得し、ローカル・システムの作業用フォルダーに入れることを、チェックアウトと言います。ローカル・ファイルに変更を加え、リポジトリーにある変更と同期させたい場合には、アップデートを行います。変更されたファイルをリポジトリーに戻すためにチェックインすることを、コミットと言います。もし、変更したファイルがその前に変更されており、誰か他の人によってコミットされていると、マージが起こります。つまり 2 つの変更セットは一緒にまとめられます。ファイルに対する変更が競合しているためマージできない場合には、競合が起きています。この状況では、コミットは拒否され、開発者は変更を手動でマージする必要があります。変更がコミットされると、そのファイルに対する新しいリビジョンが作成されます。
1 人以上の開発者が、メイン・ツリー (現在の、リポジトリーの先頭) とは別に操作を行ったり、メイン・ツリーの脇にある個人的なブランチで操作を行ったりすることができます。そのため開発者は、メイン・ツリーに影響を与えずに自分のブランチでさまざまなことを試すことができます。そして、試したものが安定したら、そうしたブランチをメイン・ツリーにマージします。
ソース・ツリーの進化の過程で、記録に残しておくとよい内容をマーキングするために、一連のリビジョン・ファイルにタグを付けることができます。こうすると、一連のファイルをグループにまとめることができ、扱いやすくなります (まとめられたものは、ある固有のビルドのためのファイル・リリースとして使われることがあります)。
アーキテクチャー
SCM にはさまざまな種類があり、それぞれ大きく異なりますが、基本的なアーキテクチャーは次のように大きく 2 つに分類されます。
- 集中リポジトリー型と分散リポジトリー型
- 変更セットモデルとスナップショット・モデル
最近の SCM のアーキテクチャー相互の差を知り、実感する上で最も重要な点は、集中リポジトリー型か分散 (または非集中型) リポジトリー型か、という違いです。今日見られる最も一般的なアーキテクチャーは、集中リポジトリー型です。このスター型のアーキテクチャーでは、集中ソース・リポジトリーがあり、それを囲むように複数の開発者が作業を行います (図 1)。開発者は、集中リポジトリーからソースコードをチェックアウトしてローカルのサンドボックスに入れ、変更を行った後、それを集中リポジトリーに戻すためにコミットします。このため、他の開発者も自分たちの変更にアクセスすることができます。
図 1. 集中型アーキテクチャーでは、すべての開発者が集中リポジトリーに対して作業を行う
またブランチも集中リポジトリーに作成されます。そのため複数の開発者が、リポジトリー上の、ただしメインライン (あるいは チップ) の外にあるソースに対して、一連の変更を加えるために協力して作業することができます。
分散アーキテクチャーでは、開発者は自分達が変更を加えるための、独自のローカルのリポジトリーを作ることができます。ローカルの開発者リポジトリーは、(分散されている) オリジナルのソース・リポジトリーと似ています。大きな違いは、集中型の手法ではサンドボックスで変更を行いますが、分散型の手法では、開発者がソース・リポジトリーに接続せずに、自分のリポジトリーに対して作業できる点です。開発者は変更を行い、その変更をローカルのリポジトリーにコミットすることができ、また他の開発者が行った変更を、メイン・ブランチに影響を与えずにマージすることができます。そうすると変更セットを、その上流のレベルの開発者が利用できるようになります。
図 2. 非集中型アーキテクチャーでは、開発者は非同期に独自のリポジトリーで作業を行う
興味深い点として、非集中型アーキテクチャーでは、独立した開発者がピアツーピアのネットワークで非同期に作業を行うことができます。作業が終わると (そして望ましくは安定すると)、その機能を他の人も利用できるように、変更セット (またはパッチ) を配布することができます。これは、Linux® カーネルを含め、今日の多くのオープンソース・システムのモデルとなっています。
スナップショット・モデルと変更セット・モデル
従来の SCM と最近の SCM のアーキテクチャー上の大きな違いとして、変更の差分の保存方法をあげることができます。どちらの方式も理論的には同じであり、結果も同じですが、リビジョンの保存方法が異なります。
スナップショット・モデルでは、リポジトリー全体に対する完全なファイルがリビジョン毎に保存されます (ただしツリーのサイズを減らすために最適化が行われます)。変更セット・モデルでは、リビジョン間の差分のみが保存され、コンパクトなリポジトリーが作られます (図 3)。
図 3. スナップショット・モデルと変更セット・モデルには、それぞれユニークな利点がある
図 3 を見るとわかるように、モデルは異なりますが、結果は同じです。スナップショット・モデルの方が早くリビジョンを取得できますが、リビジョンを保存するために、より多くのスペースが必要です。変更セット・モデルはスペースが少なくて済みますが、ベースとなるリビジョンに差分を適用する必要があるため、ある特定のリビジョンを取得するための時間は長くかかる可能性があります。後で説明しますが、適用すべき差分の数を最小にするために、最適化を行うことができます。
SCM の例
集中型と分散型というアーキテクチャーで分類しながら、いくつかの SCM を見てみましょう。これから説明するとおり、一部の SCM は両方のモデルをサポートしています。
CVS
CVS (Concurrent Versions System) は、現在最も一般的な SCM の 1 つです。CVS は変更セット・モデルを使った集中型ソリューションであり、開発者は集中リポジトリーに対してソフトウェア開発の共同作業を行います。CVS はごく普通のものであり、どんな Linux ディストリビューションにも標準的な一部として含まれています。CVS の構文は単純であり、(私達の多くにとっては) 使いやすいため、複数の開発者のための SCM としても 1 人の開発者のための SCM としても、一般的な選択肢と言うことができます。
リスト 1 は、CVS コマンドの例をいくつかあげ、それぞれに簡単な説明を付け加えたものです。CVS に関して詳しくは、「参考文献」のセクションを参照してください。
リスト 1. CVS のコマンドの例
# Create a new repository
cvs -d /home/user/new_repository init
# Connect to the central repository
export CVSROOT=:pserver:user@example.com:/cvs_root
# Check out a sandbox for module project from the central repository
cvs checkout project
# Update a local sandbox from the central repository
cvs update
# Check in changes from the local sandbox to the central repository
cvs commit
# Add new files to the local sandbox (need to be committed)
cvs add <file/subdirectory>
# Show changes made in the local sandbox
cvs diff
|
ポイント・アンド・クリックで作業したい人のために、CVS には、WinCVS や (Microsoft® Windows Explorer と統合できる) TortoiseCVS などの、オープンソースのグラフィカル・フロントエンドがいくつかあります。
CVS は広く採用されていますが、欠点もあります。CVS ではファイルをリネームすることができず、また symlink など、特殊なファイルをうまく処理できません。変更の追跡は、変更毎ではなくファイルとして追跡する必要があるため、手間がかかります。また、マージで時々問題が起きることがあります (そのため CVS は内部的には diff3 を使っています)。
しかし CVS は便利であり、すべきことを行うことができ、また主なプラットフォームであれば、どのプラットフォームでも利用可能です。CVS は好きだけれども問題点が気になる、という人には、Subversion の方が適切かもしれません。
Subversion
Subversion (SVN) は、CVS に関する上記の問題を解決し、CVS を直接置き換えるものとして設計されました。Subversion は CVS と同様、集中型のソリューションであり、スナップショット・モデルを使っています。Subversion のコマンドは CVS のコマンドを真似たものですが、ファイルの削除やリネーム、オリジナル・ファイルに戻すための新しいコマンドがいくつか追加されています。
また Subversion では、リモート・アクセスが可能です。リモート・アクセスに使用できるプロトコルには、HTTP (Hypertext Transfer Protocol) やセキュアな HTTP、あるいはセキュア・シェル (SSH) によるトンネリングもサポートするカスタム SVN プロトコルなどがあります。
リスト 2 は、Subversion でサポートされているコマンドの一部です。この中には、CVS にはないエクステンションもいくつか含まれています。Subversion について詳しくは、「参考文献」のセクションを参照してください。ご覧のとおり、Subversion のコマンド・セットは CVS と似ているため、CVS のユーザーが乗り換えるには非常に便利です。
リスト 2. Subversion のコマンドの例
# Create a new repository
svnadmin create /home/user/new_repository
# Check out a sandbox from the central repository
svn checkout file:///server/svn/existing_repository new_repository
# Update a local sandbox from the central repository
svn update
# Check in changes from the local sandbox to the central repository
svn commit
# Add new files to the local sandbox (need to be committed)
svn add <file/subdirectory>
# Show changes made in the local sandbox
svn diff
# Rename a file in the local sandbox (requires commit to the repository)
svn rename <old_file> <new_file>
# Remove files (also removed from repository, requires commit)
svn delete <file/subdirectory>
|
Subversion も CVS と同じく、ViewCVS や TortoiseSVN といったグラフィカル・フロントエンドの中に統合することができます。また、CVS リポジトリーを Subversion に変換するツール (cvs2svn.py など) もありますが、こうしたツールは複雑なリポジトリーのブランチやタグ付けを完全には処理できないと言われています。オープンソースの他のプロジェクトと同様、そうした問題も時と共に改善されていくはずです。また Subversion は、差分のビューアーとパッチ・プログラムとして、TortoiseMerge を統合しています。
Subversion は、CVS のユーザーを苦しめたいくつかの問題 (特殊ファイルのバージョン管理や、アトミックなコミットやチェックアウトなど) を解決しています。CVS を好きな人、集中リポジトリー型の手法を採用している開発者にとっては、Subversion こそが最適な SCM です。
では集中型の手法から離れ、一部の人が将来の SCM の真の姿と信ずる、コラボレーション型で非集中型のリポジトリーに移ることにしましょう。
Arch
Arch は、非集中型 SCM の仕様であり、さまざまな実装が可能です。そうした実装としては、 ArX や Bazaar、GNU arch、Larch などがあります。Arch は非集中型の SCM (図 2 を参照) として動作するだけではなく、変更セット・モデル (図 3 を参照) も採用しています。オープンソース開発では、完全なソース・コントロールを持つ別々のリポジトリーに対して開発作業を行うため、Arch SCM はオープンソース開発には一般的な方式です。つまり分散リポジトリーは、完全なリビジョン・コントロールを備えた実際のリポジトリーなのです。ローカル・リポジトリーの中で変更からパッチを作成することができ、そのパッチを上流の開発者が使用できます。これこそ、非集中型モデルの底力と言えるでしょう。
Arch も Subversion と同様、CVS の問題のいくつかを修正しています。修正された問題としては、メタデータの変更 (リビジョニング・ファイルのパーミッション) や、ファイルの削除やリネームの処理、アトミックなチェックイン (チェックインを、個々のファイルではなく 1 つのグループにまとめる) などがあります。
リスト 3 は、Arch SCM のコマンドの一部を示したものです。ここでは GNU arch を選びましたが、その理由は Arch のアーキテクト、Tom Lord によって開発されたものだからです。GNU arch は、Subversion に見られる新機能を含め、SCM に期待される基本的な機能を提供しています。
リスト 3. GNU arch のコマンドの例 (tla)
# Register a public archive
tla register-archive http://www.mtjones.com/arch
# Check out a local repository from the upstream repository
tla get project@mtjones.com--dev/project--stable myproject
# Update from the local repository
tla update
# Check in changes to the local repository
tla commit
# Add new files to the local repository (need to be committed)
tla add <file>
# Show changes made in the local repository (patch format)
tla what-changed
# Rename a file in the local repository (requires commit to the repository)
tla mv <old_file> <new_file>
# Remove files (also removed from repository, requires commit)
tla rm <file>
|
また Arch では、上流のリポジトリーでの変更を、star-merge を使ってマージすることができます。ベースのリビジョンに (変更モデル毎に) 適用すべきパッチの数を最小限にとどめるためには、cacherev コマンドを使って、リポジトリーの中のベース・リビジョンの新しいスナップショットを作成します。
Arch の利点は、非集中型の処理用に設計されているにもかかわらず、集中リポジトリー方式にも使える点です。
tla を新たに使い始めたユーザーにとって最大の不満は、tla が少し複雑なことです。baz など他の Arch 実装は、tla よりも単純だと言われています。tla では目的に沿わない場合には、そうした他の実装を試した方がよいかもしれません。
最後に、Linux カーネルの維持管理者、Linus Torvalds 自身が作成した非集中型の SCM を見ることにしましょう。
Git
Git SCM は Bitkeeper SCM (「参考文献」を参照してください) の置き換えとして、Linus Torvalds によって開発されました。Git は非常に単純ですが、非集中型で変更セット・ベースの SCM としての処理を行い、Linux カーネル用の SCM として使われています。Git は、単一のファイルを追跡するのではなく、ファイル・グループ・モデルを使っています。変更セットは圧縮され、SHA1 によるハッシュで完全性を証明しています (リスト 4)。
リスト 4. Git のコマンドの例
# Get a Git repository (first time)
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# Update a Git repository from the defined upstream Git repository
git pull
# Checkout from the Git repository into the local working repository
git checkout
# Commit changes to the local Git repository
git commit
# Push changes to upstream (requires SSH access to upstream
git push
# Add new files to the local repository (requires commit)
git add <file>
# Show changes made to the local working directory
git diff
# Remove files (requires commit)
git rm <file>
|
Git SCM は、独自の Git リポジトリーの中で自己ホストされています。つまりローカル・マシンにインストールするためには、Git をブートストラップする必要があります。Git のコマンド・セットは上で見てきたものと似ていますが、比較的基本的なものです。
皆さんは、なぜ世の中にある既存の SCM を使わないのか、と尋ねるかもしれません。それは妥当な質問です。Git は興味深い SCM であり、Linux カーネルのハッカーという大きなユーザー・ベースに応えるものです。そのため Git は、次の重要な SCM となるかもしれません。Linus は、Git を、非常に高速なディレクトリー・コンテンツ・マネージャーであり、多くのことは行わない代わりに、非常に効率的な管理を行うものと説明しています。
SCM の利点
どのようなタイプの SCM を使うにせよ、SCM を使うことによる一般的な利点があります。SCM によって、ファイルへの変更を追跡し、ソフトウェアの進化をたどることができます。不適切な変更が行われた場合には、それを見つけることができ、オリジナルのソースに戻すことができます。一連のファイルのリビジョンをグループにまとめてタグ付けし、リリースを作ることができます。こうしたリリースはいつでもチェックアウトでき、それを使って特定のコード・リリースを繰り返しビルドすることができます (これは SCM の必須事項です)。
集中型のリポジトリーを使うにせよ分散型のリポジトリーを使うにせよ、またスナップショット・モデルをモデルを使うにせよ変更セット・モデルを使うにせよ、SCM の利点は同じです。最近のソフトウェア開発プロジェクトでは、SCM は必要不可欠です。初期の段階から SCM を使い、そして頻繁に SCM を使ってください。
まとめ
この記事は、必須のものとして、今日使われている SCM のごく表面に触れたにすぎません。オープンソースの SCM には、これらの他にも、Aegis や Bazaar-NG、DARCS、Monotone など、無数にあります。エディターや言語の場合と同じく、SCM についても議論は沸騰しがちですが、正解はありません。もし、あるツールを使うことによって生産性を高められるのであれば、それを使うべきです。SCM は問題を生じがちですが、それは SCM が単独で使われることが稀であり、通常は個人ではなくチームによって SCM が選択されるためです (独裁的なボスが決めてしまうような場合は別ですが)。従って、どんなことができるのかを試し、いくつかの異なるスタイルに慣れるべきです。SCM はソフトウェア開発にとって必要であり、皆さんのエンジニアリング・ツールボックスの一部として常備すべき貴重なツールなのです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | M. Tim Jonesは、埋め込みソフトウェアのエンジニアであり、GNU/Linux Application Programming, AI Application Programming と BSD Sockets Programming from a Multilanguage Perspective の著者でもあります。エンジニアとして経歴は幅広く、静止衛星用のカーネル開発から埋め込みシステム・アーキテクチャー、そしてネットワーク・プロトコル開発まで経験しています。現在はEmulex Corp.のシニア主席エンジニアです。 |
記事の評価
| 
