はじめよう!subversion

 

2010/01/17一部改訂)

 

ブランチを作るには

$ svn copy <trunk url> <branch url> -m <msg>

(例えば、プロジェクトの下にtrunkbranchesというディレクトリを設け、ここにtrunkブランチとbranchesの下にそれぞれのブランチを追加していくポリシーでは以下の様になる)

リポジトリレイアウトの開始

 

$ svn checkout <http://svn.dkib.com/repos/calc> <working dir>

でトランクをチェックアウト

 

$ svn copy trunk branches/mybranch

mybranchというブランチをtrunkを元に作成(実質的には、コピー)

 
$ svn copy http://svn.example.com/repos/calc/trunk \
       http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Creating a private branch of /calc/trunk"

でも同じことが出来る。

 

$ svn checkout <http://svn.dkib.com/repos/calc/branches/mybranch> <working dir>

でブランチをチェックアウト

 

マージするには

$svn log -verbose integer.c       (このコマンドでどのリビジョンから枝分かれしたか確認できる)

 

$svn log -verbose stop-on-copy integer.c  (このコマンドだとさらにどのリビジョンでコピーされたか確認できる)

 

あるファイルの履歴のブランチ化

$ svn merge -r 341:343 http://svn.example.com/repos/calc/trunk

上図の例に対してこのコマンドを発行すると(今trunkの作業コピー上にいるとして)、subversiontrunk上のリビジョンr344に対して、my-calc-branchのリビジョンr341からr343までの間に起こった変更の内容をマージしようと試み、その結果をローカルの作業コピー(この場合引数が省略されているのでカレントディレクトリ、つまりtrunkの作業コピー)に保存しようとする。

 

$ svn merge <マージ受入先> <マージ投入元> <マージ結果保存先作業コピー>

もしくは以下の略記法、

$ svn merge [ -r REVm:REVn <url> | <url a> <url b> ]

でマージを敢行する。

 

マージ内容を確認するには

$ svn diff [ -r REVm:REVn <url> | <url a> <url b> ]

で内容の違いの詳細を表示

 

$ svn merge dry-run [ -r REVm:REVn <url> | <url a> <url b> ]

で実際にはマージを敢行しないが、変更が予想されるファイルの一覧を表示

 

マージの衝突

マージが衝突すると、filename.working, filename.left, filename.rightという一時ファイルが作成される。衝突を解消するには、これらのファイルを手がかりに内容を吟味、補正したのち、svn resolvedコマンドを発行して、subversionに衝突が解消されたことを通知する。

 

マージの取り消し

$ svn merge -r REVn:REVm <url>     (ただし、n > m

で、nからmまでの変更をマージしてあった場合、それを取り除くことが出来る。

 

Apache上へのSubversionのインストール

mod_dav_svn.somod_auth_svn.soのファイルは1.4.2の場合binの下にある。これを$APACHE_HOME/modulesの下にコピー。

libdb43.dlllibdb44.dll$APACHE_HOME/modulesの下にコピー。

 

Apache の設定ファイル (通常 C:\Program Files\Apache Group\Apache2\conf\httpd.conf)を、メモ帳のようなテキストエディタで以下のように編集する。

以下の行のコメントをはずし ('#' マークを消し) てください。

#LoadModule dav_fs_module modules/mod_dav_fs.so

#LoadModule dav_module modules/mod_dav.so

また、以下の2行を LoadModule セクションの最後に追加してください。

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

 

httpd.confに以下のエレメントを追加する。

#

# Subversion Location

#

<Location /svn>

         DAV svn

         SVNListParentPath on

         SVNParentPath F:\SVN

         AuthType Basic

         AuthName "Subversion repositories"

         AuthUserFile passwd

         #AuthzSVNAccessFile svnaccessfile

         Require valid-user

</Location>

 

レポジトリを作るには

$SVNの下にフォルダを作成し、以下のコマンドをDOSプロンプトから発行。

肝心なことは、リボジトリロケーションに直接リポジトリを作成する必要があるということ。おそらくインポートも出来るに違いない。

 

> svnadmin create --fs-type bdb MyNewRepository

もしくは

> svnadmin create --fs-type fsfs MyNewRepository

 

ブランチとタグの使い分け

Subversion 自身はタグとブランチを区別しないが、通常以下のように使い分けをする。

 

l         タグは、典型的には、プロジェクトの特定の段階で静的スナップショットを作成するのに使う。開発には使用しない。開発にはブランチを使用する。これが最初に/trunk /branches /tags というリポジトリ構造をお奨めした理由である。タグリビジョンで作業するのは 名案ではない が、手元のファイルに書き込み保護をかけられないので、誤って編集してしまうのを止められない。しかし、/tags/ を含むリポジトリパスにコミットしようとしたときに、TortoiseSVN は警告を発する。

l         既にタグ付けしたリリースについて、さらに修正を加える必要があるかもしれない。これを扱う正しい方法は、まずタグから新しいブランチを作成し、ブランチをコミットすることである。変更をこのブランチに行い、その後、新しいブランチから Version_1.0.1 といったように、新しいタグを作成する。

l         ブランチから作成した作業コピーを変更し、コミットする場合、すべての変更は新しいブランチに対して反映され、トランクには 反映されない。

 

ブランチからのトランクへのマージ

トランクで起こった変更は定期的に(少なくとも一週間に一度は)ブランチにマージしておくようにする。そうすることで、最終的にブランチからトランクへマージすることを決断したときに、両者の差分はブランチで行った変更のみになる。そうすることで、ブランチとトランクの内容を比較することによってマージすることが出来るようになる。

 

ブランチの運用方法

l         開発は基本的にトランクもしくはブランチで行う。

l         2人以上の開発者が目的の異なる変更を同時に加えたい場合、開発ブランチの作成を検討する。

l         開発ブランチが必要となった場合、どちらがトランクでどちらが開発ブランチを使うのかを検討する必要がある。仕様変更等プログラムの大きな変更を伴う方が開発ブランチ、バグ修正等比較的小規模でかつタイムリーな変更を要求される方がトランクを使うようにといった具合である。

l         一たび開発ラインが複数のブランチに分岐した場合、トランクの内容は定期的に(少なくとも一週間に一回)開発ブランチにマージされるように心がける。(さもないと、将来いざ開発ブランチをトランクにマージしようと思ったときに、すでにマージすることが不可能なくらい両者の内容が乖離してしまっている場合がある)

l         開発ブランチでの開発が終了したら、内容をトランクにマージし、用済みの開発ブランチは削除してしまってもかまわない。(これはチームの方針で残すかどうか決めておいたほうがよい)

l         リリースの前に更に品質向上のためのテストを一定期間必要とするならば、まずbranches/1.0等のテストブランチを作り、テストはそこで行う。このテスト期間中に発覚したバグはそれぞれトランクとテストブランチとの間で相互にマージしあう必要がある。この工程はとても慎重に行う必要がある。特にトランクでのバグ修正が新機能の追加のコード修正を含んでしまっている場合もあるので(それが不要な場合には)手で修正する必要も出てくる。

l         リリースの際にはタグを使う。テスト済みのbranches/1.0等のテストブランチをtags/1.0.0等のリリースモジュールとして、タグ付けする。

l         タグが付与済みのリリースモジュールにバグ等が発覚した場合、テストブランチbranches/1.0等を修正し、テストと修正の結果をtags/1.0.1といったリリースモジュールとして再度タグ付けをし、これをリリースする。(つまり、一度タグがついたものはそれ以上追加のコミットをしてはいけない

l         リリースモジュール(この場合tags/1.0.0)のリリース以降に、テストブランチ(この場合branches/1.0)上で行ったバグ修正(つまりtags/1.0.1にてリリースされるバグ修正)もトランクにマージすることを忘れてはならない。つまり、トランク以外でのすべての修正は、トランクにマージされる必要がある。