ライブラリアンがゆく(subversionのまとめ）
Advertisements
バージョン管理はライブラリアンの重要なタスクだ。
ライブラリアンは、ファイルの変更を管理し、サブチームがコミットする際のルールを作る。
例えば、
「trunkにソースのコミットをするには、チームリーダーの承認を得なければならない」
みたいなルール作りもやるし、
「3月にリリースしたバージョンに戻して再リリースしたいからよろしく」
などとふっかけられたりもする。そして、作業の大変さの割に、それに日が当たることは少ない。地味で地道な、バスケでいうとフットワークや筋力トレーニングのような仕事である。
それでも、ライブラリアンはプロジェクトを縁の下で支えている。その自負だけは失ってはいけない。
チームメンバーが安心して回プロジェクトを回していけるように、陰からでもチームのためにせっせと働くことが必要になる。
ドラッカーの著書で、こんな話がある。
ある一流の彫刻家が作った像は、誰も見ていない背中の細かい部分も手抜きなく一流の技が施されていた。
ある人が聞いた。
「なぜ君は誰も見ていないようなそんな細かいところに情熱を注ぐんだい？」
一流の彫刻家は答えた。
「誰も見なくても、神が見ているのさ」
ライブラリアンの仕事も、神が見ていると思って、誰に見られるでもなく責務を果たさねばなるまい。
以下、subversionの解説。
タグとは
それぞれに特定のリビジョン番号が付いた一連のファイルのシンボリック名のこと
プロジェクトをある時点でぶつ切りにして、その状態を保存したものと考えてよい。
タグを使って、リビジョンを記録しておくことができる。慣習上、tags以下のディレクトリは変更しないことになっている。もし変更を加えるなら、タグは事実上のブランチとして機能することになる。
タグを作るときは、通常はトランクのものをtags以下のディレクトリにコピーする。
トランクとは
メインの作業対象のコードのこと。全員が成果を共有する場として考える。
ブランチとは
なんらかの事情でトランクの開発とは切り離された状況で作業を進めたい場合に、プロジェクトを枝分かれさせる。
ブランチの変更点の管理、つまりブランチのバージョン管理は、トランクとは独立した形で行われることになる。
例）リリース直前にあるサブチームでバグが見つかった。リリースするためにはバグを修正しなければいけない！
でも、他のチームの開発も止めたくはない・・・。なので、サブチームがバグフィックスするためのブランチを切って、ブランチからリリースすることにした！
ブランチを切るときのコピーコマンド
svn mkdir -m "Creating new branch directory" svn://project/branches
→ブランチ用のディレクトリを作成する。
svn copy -m "Creating release branch" svn://project/trunk svn://project/branches/Release_branch_20120604
→trunkからブランチへリビジョンをコピーする。
ちなみに、Subversionでコピーする操作をしてブランチを作ったときの実体は、元のファイルのリビジョンへのリンクが作成されているにすぎない。
ブランチに変更を加えた場合は、元のファイルの差分として記録されていくことになる。なので、領域をほとんど消費せずブランチを作成できる。
用語集
| リビジョン | ユーザが行った変更をグループ化したもの |
| リビジョン番号 | ユーザが行った変更に対して割り当てた番号のこと |
| リポジトリ | ファイルの原本が格納される中核的な場所のこと |
| チェックアウト | 作業コピーのファイルをローカルマシンに配置するために、リポジトリからファイルを取り出すこと |
| エクスポート | リポジトリに格納されているファイルのある時点でのスナップショットを取得すること |
| コミット | ファイルに加えられた変更をリポジトリに戻すプロセスのこと |
| アップデート(更新) | 他のメンバーの変更点をローカルの作業コピーに反映させること |
コマンド集
| コマンド | 意味 |
|---|---|
| svnadmin create hoge | データを格納するためのリポジトリ hoge を作成する。 |
| svn import | リポジトリにファイルをインポートする。 (例)svn import -m "import project" /home/usr/ file:///home/svn/hogeproject/trunk この例だと、ローカルの/home/usr/ディレクトリにあるファイルを、リポジトリにインポートする。最後のfile～は、ファイルのインポート先のリポジトリURLである。 |
|
svn co file:///D:/01.SVN/02.repo /03.documents |
カレントディレクトリにfile://URLで指定したリポジトリから作業コピーを取得する。 左のコマンドに加えて、末尾にコピー先を指定することも可能である。 |
| svn status hoge.txt | ファイルの状態を表示する。Mはローカルで変更されていることを示す。 |
| svn diff hoge.txt | 指定したファイルのリポジトリに格納されているバージョンとローカルコピーの差分を表示することができる。 |
| svn commit -m "add hogehoge at 20120522" | ファイルの変更作業が完了したら、最新のバージョンをリポジトリに保存する。 -m以後はコメント。 |
| svn log hoge.txt | リポジトリが実際に更新されたことを確認する。 |
| svn log --verbose hoge.txt | 各リビジョンで行われた変更の詳細を正確に確認できる。 |
| svn update | カレンドディレクトリのりビジョンを更新する。リポジトリにあるものと同じリビジョンにする。 |
| svn status --show-updates | ディレクトリのファイルより新しいバージョンがリポジトリ内に存在するかどうかを リポジトリに問い合わせて確認する。 ＊がついているものは、リポジトリ内に更新済みのファイルが存在することを示している。 |
| svn diff -rHEAD hoge.txt | hoge.txtのローカルコピーをリポジトリ内の最新のリビジョンと比較する。当たり前だが、svn updateを実行したら、差分は出なくなる。 |
| svn log -r3 hoge.txt | リビジョン３のコミット時のログを出力する。 |
| avn log -r3 --verbose hoge.txt | リビジョン３のコミット時の変更ログを詳細に出力する。 |
| svn info trunk | 作業コピーのチェックアウト元を調べる。 |
| svn checkout -r 4 file:///D:/01.SVN/02.repo | リビジョン4を指定してチェックアウトする。 |
| svn copy day.txt hoge.txt | day.txtをコピーしてhoge.txtというファイルを作成する |
| svn move hoge.txt hogehoge | 名前を変更したり、ファイルを移動する。 |
svn updateで出力されるアルファベットの意味
A:リポジトリに追加されたファイルを作業コピーに追加した
U:リポジトリにあるファイルの更新を反映した
D:リポジトリから削除されているファイルを作業コピーから削除した
G:リポジトリにあるファイルの変更点とローカルの変更点は問題なくマージされた
C:競合が検出された。ユーザが解決するまで、チェックインが実行できない
リポジトリをバックアップする
■バックアップ用にダンプファイルを出力する
D:\01.SVN>svnadmin dump 02.repo > dumpfile.20120606 * リビジョン 0 をダンプしました。 * リビジョン 1 をダンプしました。 ・・・ * リビジョン 14 をダンプしました。 * リビジョン 15 をダンプしました。
■ダンプファイルを読み込む
D:\01.SVN>svnadmin create svn-repo2 ・・・ 2012/06/06 22:42 svn-repo2
D:\01.SVN>svnadmin load svn-repo2 < dumpfile.20120606 <<< オリジナルのリビジョン 1 に基づき、新しいトランザクションを開始しました ------- リビジョン 1 をコミットしました >>> <<< オリジナルのリビジョン 2 に基づき、新しいトランザクションを開始しました <<< オリジナルのリビジョン 15 に基づき、新しいトランザクションを開始しました * パスを編集しています : seasame/trunk/hoge.txt ... 完了しました。 ------- リビジョン 15 をコミットしました >>>
もっと詳しく学ぶなら・・・
