第1章
構成管理入門  

第2章
Subversionによるバージョン管理入門

第3章
Subversionベストプラクティス

第4章
Maven2によるビルド入門

第5章
Maven2ベストプラクティスリリースの自動化

第6章
リリースの自動化

Appendix
Maven 2はまり道


※WEB+DB PRESS Vol.39掲載の記事を載せています。

第2章 Subversionによるバージョン管理入門

Authors:YOSHIHARA Hidehiko

ソースファイルに関連する操作

 
編集と状態の確認
追加
削除
コピー
移動
コミット
リビジョンとタグ
 
まずは、作業コピーAで次の変更を行ってみましょう。 編集作業はいつも通りエディタを使用して行って問題ありません。その他のファイルに対する操作は Subversionの機能を使用して明示的に行う必要があります。

編集と状態の確認


hoge.txtとhoge_conflict.txtの編集を行ってみます。両ファイルとも、以下の内容に変更しました。
A
b
c
ここで、作業コピーの状態を確認してみましょう。変更の確認を行いたいディレクトリ(C:\work\2\A) に移動し、svn statusコマンドで状態の確認を行います。statusコマンドを実行すると、チェックアウトや更新後にローカルで変更されたファイルの一覧が表示されます。ファイルが変更されている場合、ファイル名の前に「M」が表示されます。

●状態の確認
 svn status
C:\work\2\A> svn status M hoge.txt M hoge_conflict.txt


追加

新規に、add_dirディレクトリとその配下にhoge_add.txtファイルを作成してください。 先ほどと同じように作業コピーの状態を確認してみましょう。
C:\work\2\A> svn status
? add_dir
M hoge.txt
M hoge_conflict.txt
「?」が出ていますね。どうやら、新規作成したディレクトリとファイルがバージョン管理の対象外とみなされているようです。
Subversionでは明示的にバージョン管理対象に追加する必要があります。追加を行いたいファイル(ディレクトリ)の親ディレクトリ(C:\work\3\A)に移動し、 svn addコマンドで追加を行います。svn addコマンドは、サブディレクトリも対象に処理を行ってくれます。

●追加
 svn add PATH
PATH:追加対象ファイル(ディレクトリ)パス

C:\work\2\A> svn add add_dir
A add_dir
A add_dir\hoge_add.txt

削除

hoge_delete.txtの削除を行います。バージョン管理の対象から外すことで、明示的に削除を行う必要 があります(注2)
削除をを行いたいファイル(ディレクトリ)の親ディレクトリ(C:\work\2\A)に移動し、svn deleteコマンドで削除を行います。svn deleteコマンドは、サブディレクトリも対象に処理を行ってくれます。

●削除
 svn delete PATH
PATH:削除対象ファイル(ディレクトリ)パス

C:\work\2\A> svn delete hoge_delete.txt
D hoge_delete.txt

コピー

hoge_copy.txtをhoge_copy2.txtにコピーします。 Subversionの機能を使用してファイル(ディレクトリ)のコピーを行います。
コピーしたいファイル(ディレクトリ)の親ディレクトリ(C:\work\2\A)に移動し、svn cpコマンドでコピーを行います。

●コピー
 svn cp SRC DST
SRC:コピーするファイル(ディレクトリ)パス DST:コピー先ファイル(ディレクトリ)パス

C:\work\2\A> svn copy hoge_copy.txt hoge_copy2.txt
A hoge_copy2.txt

移動

hoge_move.txtをhoge_move2.txtに移動してみます。Subversionの機能を使用して明示的にファイル (ディレクトリ)の移動を行う必要があります。 移動を行いたいファイル(ディレクトリ)の親ディレクトリ(C:\work\2\A)にて、svn mvコマンドで移動を行います。

●移動
 svn mv SRC DST
SRC:移動前ファイル(ディレクトリ)パス DST:移動後ファイル(ディレクトリ)パス

C:\work\2\A> svn move hoge_move.txt hoge_move2.txt
A hoge_move2.txt
D hoge_move.txt

コミット

ここまでで作業コピーAに一通り変更を行ってきましたが、作業コピーAの変更内容をリポジトリに反映させるために「コミット」と呼ばれる作業を行う必要があります。 コミットを行うディレクトリ(C:\work\2\A)に移動し、svn commitコマンドでコミットを行います。

●【コミット】
 svn commit -m "コメント"
-m:コミット時のログとして管理されるコメント

C:\ work\ 2\ A> svn commit -m "練習としてコミットしました"
追加していますadd_dir
追加していますadd_dir\ hoge_add.txt
送信していますhoge.txt
送信していますhoge_conflict.txt
追加していますhoge_copy2.txt
削除していますhoge_delete.txt
削除していますhoge_move.txt
追加していますhoge_move2.txt
ファイルのデータを送信中です...
リビジョン2をコミットしました。
注2)なお、手動でファイルを削除すると、コミットしても検出されないなど、不完全な状態に陥ります。svn statusコマンドによる確認時には 「!」と表示されます。svn updateコマンドで復活することもあれば、svn revertコマンドで戻さなければいけないこともあります。

リビジョンとタグ

作業コピーに対して行ったさまざまなファイル操作は、commitの履歴として一つにまとめられ、リポジトリに「リビジョン」と呼ばれる状態として管理されます。 先ほど行ったcommitがリポジトリに反映されているかどうか、Subversionのログを確認してみましょう。ログを参照する作業コピーに移動し、svnlogコマンドでログの表示を行います。

●ログの参照
 svn log PATH
PATH:対象のファイル(ディレクトリ)。省略時は、カレント以下すべてのパスがログ出力の対象になる

C:\work\2\A> svn log
---------------------------------------------------------------
r1 | gihyo | 2007-05-07 20:33:20 +0900 (月, 07 5 2007) | 1 line
初期インポートしました
---------------------------------------------------------------
おや、ログに先ほどのcommit情報がありません。よく勘違いすることなのですが、svn logコマンドは、作業コピーが管理しているリポジトリの履歴を表示するだけです。また、commitコマンドは、リポジトリが作業コピーの情報を取得(pull)するだけで、リポジトリから作業コピーへの情報の反映(push)は行われません。そのため、commitを行っただけでは作業コピーで管理されているリポジトリの情報は以前のまま変わらないのです。 svn updateコマンド(詳細は後述)で作業コピーの状態をリポジトリの最新状態に更新し、もう一度ログを確認してみましょう。
C:\work\2\A> svn update
リビジョン2に更新しました。
C:\work\2\A> svn log
---------------------------------------------------------------
r2 | gihyo | 2007-05-07 20:48:55 +0900 (月, 07 5 2007) | 1 line
練習としてコミットしました
---------------------------------------------------------------
r1 | gihyo | 2007-05-07 20:33:20 +0900 (月, 07 5 2007) | 1 line
初期インポートしました
---------------------------------------------------------------
今度はちゃんと表示されましたね。ログに表示されている「r2」などは「リビジョン番号」と呼ばれるものです。これはリポジトリの状態(リビジョン)を番号で表したもので、リポジトリに変更が行われ、リビジョンが作成されるごとに採番されていきます。バージョン管理では、このリビジョンの集まり(バージョン管理ツールで管理されているファイルが時間と共に変更していく過程)を「コードライン」と呼んでいます。

リビジョンは、リポジトリのある瞬間のスナップショット(状況)を表しています。リビジョン番号がわかれば、過去のリポジトリと同じ状態を作業コピーに取得できます(ちなみにCVSでは、リビジョン番号はファイルごとに割り当てられています)。バージョン管理の利点として挙げた「以前の状態に戻すことができる」のは、このリビジョン番号を参照することにより実現できるのです。
ただし、すべてのリビジョン番号とその状態を覚えておいたり、ログの中から探したりするのは大変です。そこでSubversionでは、スナップショットに対して「タグ」と呼ばれる別名を付けることで、リビジョン管理を容易に行えるようになっています(図3)。
図3 リビジョンとタグの概念図

タグは、リポジトリのtags領域に、好みの名前でリビジョンのコピーを作成して希望する状態を保持する機能です。 試しに、「TAG-1.0.0」という名前でタグを作成してみましょう。バージョン管理されているディレクトリ(C:\work\2\A)に移動し、svn copyコマンドで今のリポジトリのHEAD(リビジョン2)を対象にコピーを行います。
C:\work\2\A> svn copy
file:///C:/webdb39/2/example1/trunk
file:///C:/webdb39/2/example1/tags/TAG-1.0.0 -m "
バージョン1.0.0" (実際は1行)

リビジョン3をコミットしました。
作成したタグTAG-1.0.0のHEADをチェックアウトすることで、リビジョン2の状態をいつでも作業コピーとして取得できます。
ただし注意として、この作業コピーに対して変更を加え、タグに対してコミットを行った場合は、タグに新しいリビジョンが作成されて、タグのHEADリビジョンが変更されてしまいます。もし、タグに保持したリビジョンをもとに変更を加えたい場合は、タグからブランチを作成し、そのブランチに対して変更作業を行ってください(ブランチについては後述)。あくまでタグは、任意のリビジョンに対するラベルだと考えてください。

[Backlog] - Subversion -