TortoiseSVN は Windows 2000 SP2, WinXP 以上で動作します。Windows 98, Windows ME, Windows NT4 は TortoiseSVN 1.2.0 からサポートされませんが、本当に必要なら旧バージョンをまだダウンロードできます。

TortoiseSVN のインストール中やインストール後に問題が発生したら、はじめに 付録A よくある質問 (FAQ) を参照してください。

TortoiseSVN には簡単に使えるインストーラがあります。インストーラファイルをダブルクリックし、後は手順に従ってください。後の面倒はインストーラが見てくれます。

TortoiseSVN のユーザインタフェースはたくさんの言語に翻訳されており、ご希望の言語パックをダウンロードできるでしょう。言語パックは私たちの翻訳ページ translation status page で見つけられると思います。まだ言語パックが用意されていないのなら、チームに参加して翻訳をしてみましょう;-)

言語パックごとに .exe インストーラとしてパッケージ化されています。インストールプログラムを実行し、説明に従ってください。再起動すると翻訳が有効になります。

TortoiseSVN にはコミットログメッセージをチェックするようスペルチェッカが含まれています。プロジェクト言語が、あなたのネイティブ言語でない場合に特に便利です。スペルチェッカは OpenOffice や Mozilla と同じ辞書を使用します。

インストーラは自動でUS ないし UK の英語辞書を追加します。その他の言語を使用したければ、一番簡単なのは TortoiseSVN の言語パックをインストールすることです。TortoiseSVN のローカルユーザインターフェースと同様に、適当なディレクトリにインストールされます。再起動するとこの辞書が有効になります。

もしくは辞書を自分でインストールすることもできます。OpenOffice か Mozilla がすでにインストールされていれば、そのアプリケーションがインストールされているフォルダにある辞書をコピーできます。そうでなければ、辞書ファイルを http://wiki.services.openoffice.org/wiki/Dictionaries からダウンロードする必要があります。

辞書ファイルを取得したら、おそらくロケール文字のみの形に名前を変更する必要があります。例:

これを TortoiseSVN をインストールしたフォルダの bin サブフォルダにコピーするだけです。通常は C:\Program Files\TortoiseSVN\bin のはずです。bin サブフォルダを散らかしたくなければ、その場所の代わりに、スペルチェッカファイルを C:\Program Files\TortoiseSVN\Languages に置けます。そのフォルダがそこになければ、はじめに作成してください。TortoiseSVN の次回起動時にスペルチェッカが有効になります。

複数の辞書をインストールした場合、TortoiseSVN はどの辞書を使用するかを以下のルールで決定します。

こんなシナリオを考えてみてください。2 人の同僚 Harry と Sally がいます。2 人は同時に同じリポジトリ内のファイルを編集しようとしています。始めに Harry が変更を保存してから、(数分後に) Sally が自分の新しいファイルを偶然にも上書きすることができます。(システムが変更を記憶しているかので) Harry のバージョンが永遠に失われるというわけではありませんが、Harry が行った修正は Sally の新バージョンに隠されて見えません。Sally が Harry の変更を取り込まなかったからです。おそらく偶然ですが、Harry の作業は事実上失われたままです。こういった状況を確実に回避したいのです!

図2.2 回避したい問題

多くのバージョンコントロールシステムでは、とても単純な方法である ロック・修正・アンロック モデルでこの問題に取り組んでいます。こういったシステムでは、リポジトリはひとつのファイルにつき同時に一人しか変更できないようにしています。この場合、はじめに Harry は変更を加える前に ロック をしなければなりません。ファイルは貸し出された図書館の本のように、Harry が ファイルにロックをかけると、Sally はそこに変更を加えられなくなります。Sally がファイルをロックしようとしても、リポジトリはその要求を拒否します。できるのは、ファイルを読むことと、Harry が変更を終えてロックを解放するのを待つことだけです。Harry が変更を終えてロックを解放すると Sally はロック・編集できるようになります。

図2.3 ロック・変更・アンロック法

ロック・修正・アンロックモデルの問題は、少々制限が厳しいことで、しばしばユーザの作業の障害になります。

Subversion や CVS、その他のバージョンコントロールシステムは、コピー・変更・マージ モデルをロックの代わりに使用します。このモデルではユーザのクライアントごとにリポジトリを読み込み、ファイルやプロジェクトの個人的な作業コピーを作成します。そこからユーザは平行して作業し、個人のコピーを変更します。最後に個人のコピーを新しい最終版にマージします。バージョン管理システムはマージの補助を行いますが、正しくできたかどうかの最終的な責任は人間が負うことになります。

以下に例を挙げます。Harry と Sally はそれぞれ同じプロジェクトの作業コピーを、リポジトリからコピーして作成したとします。2人とも同時に作業し、それぞれのコピーの同じファイル A に変更を加えました。最初に Sally がリポジトリに変更を保存しました。そのあと Harry が変更を適用しようとしましたが、Harry の ファイル A は 最新ではない とリポジトリに言われてしまいました。一方、リポジトリのファイル A には Harry が最後にコピーしたときから何か変更が加わっています。そこで Harry は、リポジトリから新しい変更点を取得し、作業コピーのファイル A に マージ するように指示を出します。おそらく Sally の変更は Harry の変更に重なりません。そのため、いったん両方の変更点を統合してしまえば、作業コピーの内容をリポジトリに書き戻すことができます。

図2.4 コピー・変更・マージ法

図2.5 ...コピー・変更・マージ法 (の続き)

では、Sally の変更が Harry の変更に重なっていたら? そのときはどうなるのでしょう? この状況は 競合 と呼ばれ、普段はあまり問題になりません。Harry がクライアントプログラムに、リポジトリの最新の変更を自分の作業コピーにマージするよう指示を出すと、作業コピーのファイル A は競合状態としてマークされます。このとき彼は競合した変更を両方とも見ることができ、どちらを選ぶか選択できます。ソフトウェアが自動的に競合を解消できないことに注意してください。理解し正しく選択する力を持っているのは人間だけです。Harry がいったん重なった変更を解消したら、(Sally と競合について話し合ったあとで) マージしたファイルを安全にリポジトリに保存できます。

コピー・変更・マージモデルは少々混沌としているように見えますが、実際にはとてもスムーズに事が進みます。ユーザは他の人を待つこともなく、平行して作業を進められます。同じファイルに対して作業を行った場合でも、ほとんどの変更は重ならないことが判ると思います。そして、競合を解消するのにかかる時間は、ロックシステムで失われる時間よりもずっと少ないのです。

このことは、最終的にひとつの重要な要因にたどり着きます。ユーザ間のコミュニケーションです。ユーザがお互いに意見をやりとりしなければ、構文上・意味上の競合が増えていきます。どんなシステムもユーザに完璧なコミュニケーションを強要できませんし、意味上の競合も検出できません。したがって、ロックシステムなら競合は防げるなどという間違った思い込みで安心するなど、全く意味がありません。実際には、ロックは生産性を下げる以外のなにものでもないように見えます。

ロック・変更・アンロックモデルの方がよいといわれる一般的な状況がひとつあります。マージできないファイルがある場合です。例えば、リポジトリに画像イメージが含まれている場合、2 人の人が同時にイメージを変更してもこれをマージする方法はありません。Harry と Sally、どちらも自分の行った変更を失ってしまいます。

デフォルトで Subversion はコピー・変更・マージ法を使用しますし、ほとんどの場合この方法が常に必要だと思います。しかし、バージョン 1.2 で、Subversion はファイルのロックもサポートしました。したがって、マージできないファイルがあったり、管理するのに単にロックポリシーを強制する場合に、Subversion はそういったお好みの機能を提供することができます。

作業コピーについてはすでに説明したとおりですので、今度は Subversion クライアントで作業コピーの作成・使用について見ていきましょう。

Subversion の作業コピーは、手元のシステム上にある通常のディレクトリツリーで、ここにファイルが集められています。お望みのファイルをどれでも編集することができますし、それがソースコードのファイルなら、いつも通りそのファイルからプログラムをコンパイルできます。作業コピーはあなたの個人的な作業エリアです。Subversion が他の人の変更をここに組み込むことはありませんし、同様に、明示されるまであなたの変更が他の人から使用できるようになることもありません。

作業コピーのファイルに変更を加え、それがうまく動作することを確認したあとで、Subversion はその変更を同じプロジェクトであなたと一緒に 作業しているほかの人に 公開 するためのコマンドを (リポジトリに書き込むことで) 用意します。もし他の人が自分自身の変更を公開したとき にはSubversionはその変更を自分の作業コピーにマージするコマンドを (リポジトリの内容を読み出して) 用意します。

作業コピーには、Subversion によって作成・保守される特別なファイルがあり、その助けを受けてコマンドを実行します。特に作業コピーのディレクトリごとに .svn という名前のサブディレクトリがあり、これは作業コピーの 管理ディレクトリ として知られています。管理ディレクトリのそれぞれのファイルは、まだ公開していない変更があるか、また他の人の作業によって最新でなくなっているかを Subversion が認識する助けになります。

典型的な Subversion リポジトリは、いくつものプロジェクトのファイル (やソースコード) を保持し、リポジトリのファイルシステムツリー以下に、プロジェクトごとのサブディレクトリがあります。この配置では、ユーザの作業コピーは大抵リポジトリの特殊なサブツリーに相当します。

例えば、2 つのソフトウェアプロジェクトがあるリポジトリがあったとします。

図2.6 リポジトリのファイルシステム

言い換えると、リポジトリのルートディレクトリに paint と calc というサブディレクトリがあります。

作業コピーを取得するのに、チェックアウト をリポジトリのサブツリーに対して行わなければなりません。チェックアウト という用語はロックやリソース確保のように聞こえますがそうではなく、単にあなた専用のコピーを作成することです。

button.c への変更を行うことを思い浮かべてください。.svn ディレクトリはファイルの変更日付と元の内容を記憶していますから、Subversion はファイルが変更されていることを教えてくれます。しかし、あなたの行った変更を (あなたが明示するまで) 公開にしません。あなたが変更を公開することは、リポジトリへのコミット (やチェックイン) と呼ばれています。

あなたの変更を他の人に公開するには、Subversion の commit コマンドを使用してください。

さて、button.c への変更を、リポジトリにコミットしましたから、他のユーザが /calc の作業コピーをチェックアウトすると、あなたが行った変更が入っている最新版のファイルを見ることになります。

あなたに Sally という相棒がいて、/calc の作業コピーをあなたと同時にチェックアウトしたとします。あなたが button.c の変更をコミットしても、Sally の作業コピーは変更されないままです。Subversion はユーザのリクエストによってのみ作業コピーを更新するからです。

Sally のプロジェクトを最新にするには、Subversion に作業コピーを更新するよう指示します。これは Subversion の update コマンドを使用します。これによりあなたの変更が Sally の作業コピーに組み込まれ、またチェックアウト後にコミットされた他の人の変更も同様に組み込まれます。

Sally がどのファイルを更新するか指定する必要がないことに注意してください。Subversion は .svn ディレクトリの情報とリポジトリ内の詳細情報を用い、どのファイルを更新するか決めるのです。

Subversion リポジトリはたくさんの異なる方法 (ローカルディスクや様々なネットワークプロトコル) でアクセスできます。しかし、リポジトリの位置は常に URL で表されます。URL スキーマはアクセス方法を表します。

ほとんどの場合、Subversion の URL には標準文法を使用し、URL の中にサーバ名やポート番号を含められます。file:// アクセスメソッドは通常ローカルアクセスに使用しますが、ネットワーク上のホストに対する UNC パスにも使用できます。そのため URL は file://hostname/path/to/repos といった形式になります。ローカルマシンでは URL の hostname の部分を空にするか localhost としてください。このためローカルパスは、file:///path/to/repos のようにスラッシュが 3 つ並ぶことになります。

また Windows プラットフォームで file:// スキームを使うユーザは、同じマシン上にあるが、クライアントのカレントドライブとは別のドライブにあるリポジトリにアクセスするために、非公式の「標準」構文を使う必要があります。以下の URL パス構文のどちらか一方を使えばうまくアクセスできます。ここで X はリポジトリのあるドライブです。

file:///X:/path/to/repos
...
file:///X|/path/to/repos
...

URL は通常スラッシュを使用しますが、Windows のパス形式 (URL ではない) はバックスラッシュを用います。

ネットワーク共有上でも FSFS リポジトリには安全にアクセスできますが、BDB リポジトリにはこの方法でアクセスできません。

svn commit 操作はファイルやディレクトリの変更を、単一の不可分トランザクションで公開します。作業コピーでは、ファイルの内容を変更したり、ファイルやディレクトリの作成・削除・名前変更・コピーを、完全な変更セットの単位としてコミットできます。

リポジトリでは、コミットを不可分トランザクションとして扱い、全てをそこに置くか何も置かないかのどちらかになります。Subversion はプログラムのクラッシュや、システムクラッシュ、ネットワーク障害、他のユーザの操作に直面してもこの最小単位を保持しようとします。

リポジトリがコミットを受け付けるごとに、ファイルシステムツリーの状態が新しく作成されます。これを リビジョン と呼びます。リビジョンごとに一意の自然数が割り当てられ、前のリビジョンよりも大きくなります。リポジトリを新規作成した直後のリビジョンは 0 で、ルートディレクトリ以外はなにも含まれていません。

リポジトリを視覚化するうまい方法は、ツリーの連続で表すというものです。0 から始まるリビジョン番号が、左から右に追加されていく状況を想像してください。それぞれのリビジョン番号には対応したファイルシステムツリーがあり、それぞれのツリーはコミット後のリポジトリの状態を示す「スナップショット」です。

図2.7 リポジトリ

作業コピーがリポジトリの特定のリビジョンに常に対応しているとは限らないということに十分注意してください。複数の異なるリビジョンが混在する可能性があります。たとえば、最新リビジョンが 4 であるリポジトリから、作業コピーをチェックアウトしたとします。

calc/Makefile:4
     integer.c:4
     button.c:4

この時点では作業ディレクトリは、リポジトリのリビジョン 4 と完全に一致します。しかし、ここで button.c に変更を加え、変更をコミットしたとします。他にコミットした人がいなければ、このコミットではリポジトリにリビジョン 5 を作成し、作業コピーの内容は以下のようになります。

calc/Makefile:4
     integer.c:4
     button.c:5

この時点で、Sally がinteger.c を変更し、リビジョン 6 を作成したとします。svn update であなたの作業コピーを更新すると、以下のようになります。

calc/Makefile:6
     integer.c:6
     button.c:6

Sally の integer.c への変更は、あなたの作業コピーに現れますが、button.c へ行ったあなたの変更はそのままです。この例では、Makefile のテキストはリビジョン 4, 5, 6 で全く同じものですが、Subversion は作業コピー中の Makefile のリビジョンを 6 にして最新であることを表現します。そのため作業コピーのトップでまっさらな更新を行うと、一般的に、作業コピーはリポジトリの特定のバージョンに完全に一致します。

作業ディレクトリ内のファイルに対して、Subversion は 2 つの本質的な情報を .svn/ 管理領域に記録します。

この情報とリポジトリとのやりとりによって、Subversion は、作業ファイルが以下の4つの状態のどれかを確認できます。

さて、D:\SVN\MyNewRepository にある新しいリポジトリを作成しました。

ローカルリポジトリにアクセスするには、そのフォルダへのパスが必要です。Subversion はすべてリポジトリのパスを file:///C:/SVNRepository/ という形で表すことを覚えておいてください。一貫してスラッシュ ("/") を使用することに注意してください。

ネットワーク共有にあるリポジトリにアクセスするには、ドライブへのマッピングと UNC パスの両方が使えます。UNC パスは file://ServerName/path/to/repos/ といった形です。先頭にスラッシュ ("/") が 2 つあることに注意してください。

SVN 1.2 以前では、UNC パスは file:///\ServerName/path/to/repos というもっと曖昧な形でした。この形もまだサポートしていますが、お勧めしません。

原理上、FSFS リポジトリはネットワーク共有上に配置でき、file:// プロトコルを用いて複数のユーザがアクセスできますが、これは絶対にお勧めできません。実際、私たちは思いとどまらせようと強く思いますし、そのような使用をサポートしません。

第一に、すべてのユーザにリポジトリへ直接書き込みアクセスする権限を与えることになり、誰かが事故でリポジトリ全体を削除したり、何らかの方法で使用できなくしたりできます。

第二に、すべてのネットワークファイル共有プロトコルが、Subversion が求めるロックをサポートしているわけではなく、リポジトリが壊れた状態に見える可能性があります。すぐには起こらないかも知れませんが、ある日 2 人のユーザが、同時にリポジトリにアクセスしようとすることもあるでしょう。

第三に、ファイルのパーミッションを、まったく同じように設定しなければなりません。ネイティブの Windows 共有ではうまくいくかも知れませんが、SAMBA では特に難しいです。

file:// アクセスは、ローカルでの一ユーザのみのアクセスを想定しており、そのようにテストとデバッグを行っています。リポジトリを共有したければ、それはまさに適切なサーバをセットアップする必要があり、あなたが思うほど難しくはありません。サーバの選択・設定のガイドラインは、「リポジトリへのアクセス」 をお読みください。

データをリポジトリにインポートする前に、データをどのような構成にするかをはじめに考える必要があります。お勧めレイアウトを採用するなら、あとで楽ができるでしょう。

リポジトリの編成にはある程度、標準化された、おすすめの方法が あります。ほとんどの人々は trunkディレクトリに開発の 「主系」、ブランチコピーがある branches ディレクトリ、そしてタグコピーがある tags ディレクトリを作成します。リポジトリがただ一つのプロジェクトを含む場合には、以下のように、この三つのディレクトリをリポジトリ最上位に作ります。

/trunk
/branches
/tags

リポジトリに複数のプロジェクトがあるなら、以下のようにブランチでまとめたレイアウトにしたり、

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc

プロジェクトでまとめたりします。

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

プロジェクト同士があまり密接に連携しておらず、それぞれ個々にチェックアウトできるなら、プロジェクトごとにインデックス化するのは意味があると思います。プロジェクト同士が連携している場合には、一度に全てチェックアウトしたいと思うことでしょうし、ひとつの配布パッケージに結合されるプロジェクトなどはブランチでインデックス化する方がいいでしょう。この方法だと、ひとつのトランクをチェックアウトするだけで済み、またサブプロジェクト間の関係も容易に見て取れます。

トップレベルに /trunk /tags /branches アプローチを採用する場合、別にあらゆるブランチやタグについて全体のトランクをコピーしなければならないと言うことはありません。また、ある点ではこの構造は最も柔軟な形となります。

関連がないプロジェクトはリポジトリを分けるという選択もあります。変更をコミットする際、リビジョン番号はプロジェクトごとに振られるのではなく、リポジトリ全体の変更に振られます。関連のない 2 つのプロジェクトがリポジトリを共有するとリビジョン番号に大きなギャップが生じます。Subversion プロジェクトと TortoiseSVN プロジェクトは同じホストアドレスにありますが、独立して開発できるよう、またビルド番号で混乱しないようリポジトリが分けられています。

もちろん、以上の共通のレイアウトを無視することだってできます。あなた方によく作業できるようにならどのような類の変更でも起こせます。ここで選択したものが、永遠に続けなければならないわけではない、ということを覚えておいてください。いつでもリポジトリを再構成できます。ブランチやタグは特定のディレクトリですから、TortoiseSVN はお好みにあわせて移動したり名前を変更したりできます。

あるレイアウトから別のレイアウトへ切り替えるのは、ただ単にサーバ側での移動が問題になります。リポジトリを再構成する方法をとりたくなければ、ディレクトリを移動してください。

そのため、まだ基本的なフォルダ構造を、リポジトリに作成していないのであれば、今のうちにやっておくべきです。これを行うには、2通りの方法があります。 /trunk /tags /branches 構造を単に作成したいだけであれば、リポジトリブラウザを使用して、3つのフォルダを作成できます (3つのコミットに分かれます)。もっと深い階層を作成する場合は、まずディスクにフォルダ構造を作成し、その後一度にコミットする方法が簡単です。以下のように行います。

リポジトリには、中身だけでインポートしたフォルダ名は現れないことに注意してください。たとえば、以下のようなフォルダ構造を作成してください。

C:\Temp\New\trunk
C:\Temp\New\branches
C:\Temp\New\tags

リポジトリルートに C:\Temp\New をインポートすると、以下のようになります。

/trunk
/branches
/tags

Subversion には、Svnserve (通常の TCP/IP 接続上でカスタムプロトコルを使用する軽量スタンドアロンサーバ) があります。小規模構成にしたい場合や、本格的な Apache サーバを使用できない場合には申し分ありませんし、

ほとんどの場合、svnserve は Apache ベースサーバよりセットアップが簡単で、早く実行できますが、高度な機能のいくつかはありません。また今では、さらに安全にしやすくする SASL サポートも含まれています。

svnserve をインストールしたら、サーバを実行する必要があります。起動する単純な手順は、DOS のシェルから以下のようにするか、Windows のショートカットを作成することです。

svnserve.exe --daemon

svnserve が起動し、ポート 3690 でリクエストを待ち受けます。--daemon スイッチは、svnserve に daemon プロセスとして実行するように指示します。そのためすでに実行されている場合は、手動で終了する必要があります。

まだリポジトリを作成していないなら、Apache サーバのセットアップ 「設定」 の説明を参照してください。

svnserve が作動しているかテストするため、TortoiseSVN → リポジトリブラウザ でリポジトリを参照してください。

リポジトリが c:\repos\TestRepo にあり、サーバ名が localhost とすると、リポジトリブラウザに以下のように入力します。

svn://localhost/repos/TestRepo

セキュリティを高め、URL を入力する時間を節約するために、--root スイッチを用いてサーバ上の指定したディレクトリにルートを設定し、そこだけアクセスするようにできます。

svnserve.exe --daemon --root drive:\path\to\repository\root

ガイドのように以前行ったテストの物を使用して、svnserve を以下のように実行します。

svnserve.exe --daemon --root c:\repos

すると TortoiseSVN のリポジトリブラウザでは、次のように省略できるようになります。

svn://localhost/TestRepo

--root スイッチは、あなたのサーバの svnserve の場所と違うパーティションやドライブにリポジトリがある場合にも、指定する必要があることに注意してください。

svnserve は複数のリポジトリを提供します。そのリポジトリは、定義したルートフォルダ以下に配置され、ルートからの相対パスでアクセスできます。

sc create svnserve binpath= "c:\svnserve\svnserve.exe --service 
    --root c:\repos" displayname= "Subversion" depend= tcpip 
    start= auto

sc create svnserve binpath= "
    \"C:\Program Files\Subversion\bin\svnserve.exe\"
    --service --root c:\repos" displayname= "Subversion" 
    depend= tcpip start= auto

sc description svnserve "Subversion server (svnserve)"

obj= "NT AUTHORITY\LocalService"

svnservice -remove

デフォルトの svnserve セットアップでは読取専用の匿名アクセスを提供しています。これは svn:// URL を、チェックアウト・更新に使用でき、リポジトリを見るのに TortoiseSVN のリポジトリブラウザを利用できるということです。しかしいずれの変更もコミットできません。

リポジトリへ書込アクセスを行えるようにするには、リポジトリディレクトリ内にある conf/svnserve.conf ファイルを編集する必要があります。このファイルは svnserve daemon の設定を制御します。また有用なドキュメントも含んでいます。

匿名書込アクセスを許可するシンプルな設定は、

[general]
anon-access = write

です。しかし、svn:author 属性が空のため、誰がリポジトリに変更を加えたのかがわかりません。誰が変更したのかコントロールできなくなってしまいます。いくらか危険な設定です!

これを解決するひとつの解答がパスワードデータベースを作成することです。

[general]
anon-access = none
auth-access = write
password-db = userfile

userfile は svnserve.conf と同じディレクトリに存在するファイルです。このファイルは、ファイルシステムのどこか他の場所に置くことができ (同じアクセス権が必要な複数のリポジトリがある場合に便利)、絶対パスか conf ディレクトリに対する相対パスで指定できます。パスを含める場合 /the/unix/way のように書かねばなりません。\ やドライブレターは動作しません。userfile の構造は

[users]
username = password
...

のようになります。この例は未認証 (匿名) ユーザの全アクセスを拒否し、userfile に並べたユーザに読み書きアクセスを与えます。

svnserve ベースサーバでユーザ認証を行うもう一つの方法は、リクエストを通過させるトンネルに secure shell (SSH) を利用することです。SASL のセットアップようには単純ではありませんが、様々なケースで便利だと思います。

この方法では、svnserve は daemon プロセスで実行させず、secure shell が SSH で認証したユーザに対して svnserve を起動します。これを有効にするには、secure shell daemon がサーバに必要です。

サーバをセットアップする基本的な方法は、付録G SSH を用いた安全な svnserve で得られます。その他のFAQ にある SSH の話題については、「SSH」 で検索してください。

svnserve のさらなる情報は Version Control with Subversion にあります。

Subversion 1.3 で起動すると、svnserve は、Apache サーバで有効な mod_authz_svn パスベース認証方式と同じものをサポートします。リポジトリディレクトリにある conf/svnserve.conf ファイルを編集し、認証ファイルを参照する行を追加する必要があります。

[general]
authz-db = authz

authz には、作成したアクセス制限を定義したファイルを指定してください。リポジトリごとに独立したファイルを使用できますし、複数のリポジトリで同じファイルを使用することもできます。ファイル形式の説明については、「パスベース認証」 をご覧ください。

Subversion 用にセットアップできるサーバのうち、もっとも柔軟なのは Apache ベースの物です。セットアップするには少し複雑ですが、他のサーバが提供できない特徴があります。

Apache をインストールするためには、コンピュータが Windows 2000 か Windows XP+SP1, Windows 2003, Vista, Server 2008 である必要があります。

以上で Apache と Subversion をセットアップしました。しかし Apache は、どのように TortoiseSVN のような Subversion クライアントを扱うかをまだ知りません。Subversion リポジトリが使用する URL を Apache に教えるために、Apache 設定ファイル (通常、c:\program files\apache group\apache2\conf\httpd.conf) をお好みのテキストエディタ (例: メモ帳) で以下のように編集してください。

以下は入力する部分の短い説明です。

これは例でしかありません。Apache ウェブサーバにはもっとずっとたくさん設定項目があります。

SVNParentPath ディレクティブを使用する場合、新しいリポジトリを作成する際に Apache 設定ファイルを変更する必要はありません。単にはじめのリポジトリと同じ場所に、新しいリポジトリを作成してください。これで終わりです! 筆者の会社では、SMB (通常の Windows ファイルアクセス) で指定のフォルダに直接アクセスできています。ここに新しいフォルダを作成し、TortoiseSVN コマンド TortoiseSVN → ここにリポジトリを作成... を実行すると新しいプロジェクトのホームができます...

Subversion 1.3 以降を使用している場合、ブラウザで個々のリポジトリを指定するのではなく上位パスを指定して、有効なプロジェクトの一覧を Apache が表示できるよう、SVNListParentPath on ディレクティブを使用できます。

mod_authz_svn モジュールは、ユーザ名とリポジトリパスを元にしたアクセス制限のきめ細かい制御を行えます。これは Apache サーバで利用でき、また Subversion 1.3 では svnserve でも同様に利用できます。

サンプルファイルは以下のようになります。

[groups]
admin = john, kate
devteam1 = john, rachel, sally
devteam2 = kate, peter, mark
docs = bob, jane, mike
training = zak
# Default access rule for ALL repositories
# Everyone can read, admins can write, Dan German is excluded.
[/]
* = r
@admin = rw
dangerman =
# Allow developers complete access to their project repos
[proj1:/]
@devteam1 = rw
[proj2:/]
@devteam2 = rw
[bigproj:/]
@devteam1 = rw
@devteam2 = rw
trevor = rw
# Give the doc people write access to all the docs folders
[/trunk/doc]
@docs = rw
# Give trainees write access in the training repository only
[TrainingRepos:/]
@training = rw

すべてのパスをチェックするのは、(特にリビジョンログに関して) 時間がかかる操作だということに注意してください。サーバは、リビジョンごとにすべてのパスを変更があるかチェックし、そこが読み込めるかどうかをチェックします。リビジョンにあるファイルが多くなれば、時間をどんどん消費してしまいます。

認証 (authentication) と許可 (authorization) は独立したプロセスです。ユーザがリポジトリパスへアクセスしたい場合、通常の認証条件とファイルへのアクセス許可条件を両方満たさなくてはなりません。

お気づきのように passwd ファイルに、ユーザごと別々に ユーザ名/パスワードのエントリを作成しなければなりません。 そして、(安全上の理由で) ユーザに定期的にパスワードを変えて欲しいなら、手動で変更しなければなりません。

しかし少なくとも、Windows のドメインコントローラを利用するLANの内部からリポジトリにアクセスするなら、この問題の解決法があります。mod_auth_sspi です!

オリジナルの SSPI モジュールはソースコード込みで Syneapps から提供されていましたが、現在開発が止まっています。しかし、がっかりすることはありません。コミュニティが拾い上げ、改良を行っています。新しいホームは SourceForge にあります。

SSPI を使用して認証を行う場合、パスワードファイルを定義するのに AuthUserFile の行はもう必要ありません。Apache はユーザ名とパスワードを Windows ドメインで認証します。DOMAIN\username を参照するよう svnaccessfile のユーザ一覧を更新する必要があります。

また、Subversion リポジトリに複数の認証ソースを持つこともできます。それには、いずれの認証タイプも権威を持たないようにします。すると Apache は、ユーザ名とパスワードの検証に、複数のソースをチェックするようになります。

Windows ドメイン認証と passwd ファイル両方を使用するというのが、よくあるシナリオです。これにより、Windows ドメインログインできないユーザも、SVN アクセスができるようになります。

以下は、Windows ドメインと passwd ファイル認証を組み合わせた Apache の全設定のサンプルです。

<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath D:\SVN

  AuthName "Subversion repositories"
  AuthzSVNAccessFile svnaccessfile.txt

# NT Domain Logins.
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative Off
  SSPIDomain <domaincontroller>
  SSPIOfferBasic On

# Htpasswd Logins.
  AuthType Basic
  AuthBasicAuthoritative Off
  AuthUserFile passwd

  Require valid-user
</Location>

Apache 2.2.x では OpenSSL をサポートしていますが、デフォルトでは有効になっていません。手動で有効にする必要があります。

<Location /svn>
  DAV svn
  SVNParentPath D:\SVN
  SSLRequireSSL
  AuthType Basic
  AuthName "Subversion repositories"
  AuthUserFile passwd
  #AuthzSVNAccessFile svnaccessfile
  Require valid-user
</Location>

Nigel Green さんが TortoiseSVN のメーリングリストに投稿した内容です。ありがとうございます!

サーバの構成によっては、2 つ仮想 SSL ホストをひとつのサーバにセットアップする必要があるかも知れません。ひとつはクライアント証明書のいらず、web アクセスが公開されています。二つ目はクライアント証明書が必要な安全なサーバで、Subversion サーバを動作させています。

SSLVerifyClient Optional ディレクティブを、Apache 設定ファイルの サーバごとの セクション (つまり VirtualHost ブロックと Directory ブロックの外側) に追加すると、最初の SSL ハンドシェイクでクライアント証明書を要求するように、強制できます。mod_ssl のバグにより、SSL 接続を再ネゴシエーションする場合、動作していないときと同じように、この時点で証明書が必要になるのは避けられません。

解決策は、Subversion でロックしたい仮想ホストのディレクトリに、以下のディレクティブを追加することです。

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

クライアント証明書を受け取り、検証に成功した場合だけ、このディレクティブは、そのディレクトリへのアクセスを許可します。

まとめると、Apache 設定ファイルの関係する行は、以下のようになります。

SSLVerifyClient Optional

### Virtual host configuration for the PUBLIC host 
### (not requiring a certificate)

<VirtualHost 127.0.0.1:443>
  <Directory "pathtopublicfileroot">
  </Directory>
</VirtualHost>

### Virtual host configuration for SUBVERSION 
### (requiring a client certificate)
<VirtualHost 127.0.0.1:443>
  <Directory "subversion host root path">
    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
  </Directory>

  <Location /svn>
    DAV svn
    SVNParentPath /pathtorepository
  </Location>
</VirtualHost>

図4.1 エクスプローラのアイコンオーバーレイ表示

TortoiseSVN の目立つ機能に、作業コピーのファイルに現れるアイコンオーバーレイがあります。これにより、ファイルが変更されているかどうかが一目瞭然となります。オーバーレイが表現する内容については 「アイコンオーバーレイ」をご覧ください。

図4.2 バージョン管理下のディレクトリに対するコンテキストメニュー

すべての TortoiseSVN コマンドは、Windows エクスプローラのコンテキストメニューから呼び出されます。ファイルやフォルダを 右クリック すると、ほとんどは直接見えています。ファイルやフォルダであるかどうか、その親フォルダがバージョン管理下にあるかどうかでそのコマンドは有効になります。TortoiseSVN メニューを、エクスプローラのファイルメニューの一部としても見ることができます。

いくつかの場合、TortoiseSVN エントリを、複数眼にするかもしれません。これはバグではありません!

図4.3 バージョン管理フォルダでショートカットする、エクスプローラのファイルメニュー

この例では、バージョン管理下のフォルダ内にバージョン管理外のショートカットがある場合、エクスプローラのファイルメニューに TortoiseSVN のエントリが 3 つ あります。ひとつはフォルダ用、ひとつはショートカットそのもの用、最後にショートカットが指し示すオブジェクト用です。以上を見分けるのに、ファイル、フォルダ、ショートカットのメニューエントリか、複数選択した項目かに関係なく、アイコンの右下にマークがつきます。

Windows 2000 を使用している場合、コンテキストメニューはテキストのみとなり、メニューアイコンがつきません。以前のバージョンでは動作していましたが、Microsoft が Vista 用にアイコンハンドラの動作を変更したため、別の表示方法をとらねばならず、申し訳ありませんが Windows 2000 では動作しなくなりました。

図4.4 バージョン管理下のディレクトリに対する右ドラッグメニュー

作業コピーの中にファイルやフォルダを 右ドラッグ したり、バージョン管理下のディレクトリにバージョン管理外のファイルやフォルダを 右ドラッグ すると、そのドラッグハンドラによって他のコマンドが有効になります。

共通の操作は Windows のショートカット出よく知られたものですが、ボタンに表示されるわけではありませんし、メニューもありません。行き詰まってしまったら、リフレッシュを兼ねてここをチェックしてみてください。

アクセスしようとしているリポジトリがパスワードで保護されている場合、認証ダイアログが表示されます。

図4.5 認証ダイアログ

ユーザ名とパスワードを入力してください。TortoiseSVN が証明書を Subversion のデフォルトディレクトリ (%APPDATA%\Subversion\auth) にある、以下の 3 つのサブディレクトリに格納するかどうかチェックボックスで指定できます。

全サーバの認証キャッシュをクリアしたければ、TortoiseSVN 設定ダイアログの保存データ ページから行えます。このボタンで、以前のバージョンでレジストリに格納した認証情報と同様に、Subversion の auth ディレクトリからキャッシュされた認証データをクリアします。「保存データの設定」 をご覧ください。

Windows のログオフ時やシャットダウン時に、認証データを削除したいと言う人もいます。そのようにするには、%APPDATA%\Subversion\auth ディレクトリを削除するシャットダウンスクリプトを使用します。以下のようになります。

@echo off
rmdir /s /q "%APPDATA%\Subversion\auth"

このようなスクリプトをインストールする方法は、windows-help-central.com に説明があります。

サーバの認証やアクセスコントロールのセットアップ方法について詳細な情報は、「リポジトリへのアクセス」 を参照してください。

TortoiseSVN のダイアログの多くは、大量の情報を表示します。しかし画面全体の最大化よりも、縦方向の最大化や、横方向の最大化が便利なことがあります。

すでにいくつかのプロジェクトが登録されている、既存リポジトリにインポートする場合、リポジトリ構造はすでに決まっていることでしょう。新しいリポジトリにデータをインポートする場合には、どのようにリポジトリを構成するかを考えるのに、時間を費やす価値はあります。もっと深いアドバイスが必要であれば、「リポジトリレイアウト」 をお読みください。

この節では、ディレクトリ階層をリポジトリへ一度にインポートするよう設計された、Subversion の import コマンドについて説明しています。これは動作しますが、以下のようにいくつか欠点があります。

このため、import コマンドをまったく使わず、むしろ、「その場でインポート」 で説明する、2 段階法に従うのをお勧めします。しかし、あなたは今、基本的な import コマンドがどのように動作するかを説明する場にいます……

リポジトリにプロジェクトをインポートする前に、以下を行ってください。

今度は Windows エクスプローラのプロジェクトディレクトリ構造のトップレベルフォルダを選択し、右クリック でコンテキストメニューを出してください。TortoiseSVN → インポート... コマンドを選択し、ダイアログボックスを表示します。

図4.6 インポートダイアログ

このダイアログに、プロジェクトにインポートしたいリポジトリの場所を示す、URL を入力しなければなりません。インポートしようとするローカルフォルダ自体が現れるのではなく、その中身がリポジトリに現れるということに気づくのは重要です。例えば以下の構造があるとします。

C:\Projects\Widget\source
C:\Projects\Widget\doc
C:\Projects\Widget\images

ここで、C:\Projects\Widget を http://mydomain.com/svn/trunk にインポートすると、Widget サブディレクトリではなく、その中のサブディレクトリが直接 trunk の中にあるのに驚くかもしれません。URL の一部として、http://mydomain.com/svn/trunk/Widget-X のようにサブディレクトリを指定する必要があります。import コマンドは、リポジトリの中にサブディレクトリがない場合、自動的に作成することに注意してください。

インポートメッセージは、ログメッセージとして使われます。

デフォルトでは、共通無視パターンにマッチしたファイル・フォルダはインポートされません。この動作を上書きするには、無視されたファイルを含む チェックボックスを使用してください。共通無視パターンの設定の詳細は 「一般設定」 をご覧ください。

OK を押すと、TortoiseSVN は全てのファイルが入った完全なディレクトリを、リポジトリにインポートします。これでプロジェクトがバージョン管理下にあるリポジトリに格納されました。インポートしたフォルダは、バージョン管理下に入らないことに注意してください! バージョン管理下の 作業コピー を取得するには、インポートしたときのバージョンをチェックアウトする必要があります。もしくは、フォルダをその場でインポートする方法をご覧ください。

既にリポジトリがあると仮定したときに、新しいフォルダ構造を追加する場合、以下の手順にしたがってください。

時々、バージョン管理下のファイルにユーザごとのデータを含める必要があります。全てのユーザ・開発者が手元の環境をセットアップするときに、修正しなければならないファイルがあるということです。しかしそういったファイルは、ユーザがそれぞれいつでもリポジトリにコミットしてしまえるために、バージョン管理が難しいのです。

そういった場合、テンプレート ファイルを使うのをお勧めします。開発者が必要な全てのデータを含むファイルを作成し、そのファイルをバージョン管理下に置きます。開発者のそのファイルをチェックアウトします。それから、開発者ごとにそのファイルの コピーを作成 し、名前を変更します。そうするとコピーを変更してもなんの問題もありません。

たとえば、TortoiseSVN のビルドスクリプトを参照してください。このファイルの名前は TortoiseVars.bat ですが、リポジトリにはありません。TortoiseVars.tmpl ファイルがあるだけです。TortoiseVars.tmpl はテンプレートファイルで、開発者ごとにコピーを作成し、 TortoiseVars.bat と名前を変更するようになっています。このファイルの中には、ユーザがどの行を編集・変更すればいいか判るように、セットアップのしかたをコメントとして追加しています。

ユーザが不安にならないように、TortoiseVars.bat を親フォルダの無視リストに追加してあります。つまり、Subversion の svn:ignore 属性をそのファイルにセットしています。これにより (バージョン管理外のファイルのよう) コミットごとに表示されることがなくなります。

チェックアウトの際、子フォルダを再帰する 深度 を選択できます。大きなツリーの一部が必要なだけなら、トップレベルフォルダのみをチェックアウトし、それから選択したフォルダを再帰的に更新します。

わずかな作業コピーをチェックアウトする (チェックアウト深度を 再帰的 以外にする等) 場合、リポジトリブラウザ (「リポジトリブラウザ」) や変更をチェックダイアログ (「こちらの状態とあちらの状態」) を用いて、サブフォルダを追加で取得できます。

リポジトリブラウザでは、チェックアウトしたフォルダを 右クリック し、TortoiseSVN → リポジトリブラウザ でリポジトリブラウザを表示してください。作業コピーに追加するサブフォルダを探し、項目を特定リビジョンへ更新... を使用してください。このメニューは、作業コピーに親項目が存在し、かつ選択した項目が存在しない場合にのみ表示します。

変更をチェックダイアログでは、まず、リポジトリをチェック ボタンをクリックしてください。リポジトリにあるが、チェックアウトされていないファイル・フォルダを、リモート操作による追加 として、すべてこのダイアログに表示します。作業コピーに追加したいフォルダを 右クリック し、コンテキストメニュー → 更新 としてください。

この機能は、大きなツリーの一部をチェックアウトする時だけでなく、ひとつの作業コピーを更新する際にも非常に便利です。Project01 から Project99 といったサブフォルダがある大きなツリーがあり、Project03, Project25, Project76/SubProj だけチェックアウトしようとしていると仮定しましょう。以下のような手順となります。

作業コピーが最新で競合がない場合、変更をコミットする準備ができています。コミットするファイルやフォルダを選択し、TortoiseSVN → コミット... を行ってください。

図4.8 コミットダイアログ

コミットダイアログには変更したファイルが、追加・削除・バージョン管理外を含め表示されます。変更したファイルをコミットしたくない場合は、ファイルのチェックをはずしてください。バージョン管理外のファイルを含める場合は、追加・コミットするファイルのチェックをつけてください。

別のリポジトリパスに切り替えた項目には、(s) マークが付きます。何かを切り替えてブランチで作業した後、トランクに戻すのを忘れている可能性もあります。これは警告マークです!

svn:externals を使って別のリポジトリから取得したファイルにも変更がある場合、その変更を同時に不可分コミットできません。この場合、警告シンボルがファイルリストにつき、外部参照ファイルは別々にコミットしなければならないとツールチップで教えてくれます。

コミットダイアログで変更のあるファイルを ダブルクリックする と、変更を確認するよう外部差分ツールが起動します。スクリーンショットにあるようにコンテキストメニューでもっとオプションを指定できます。ここからファイルをドラッグして、テキストエディタや IDE といったアプリケーションに持っていくこともできます。

項目の左にあるチェックボックスをクリックして、選択・未選択を切り替えられます。ディレクトリに対して、Shift を押しながら選択 すると、再帰的に動作します。

下のペインに表示された列は、カスタマイズできます。列見出しの上で 右クリック すると、表示する列を選択するコンテキストメニューを表示します。また、列の境界上にマウスを持っていくとドラッグハンドルを表示し、列幅を変更できます。以上のカスタマイズは保存されるので、次回以降も同じ列見出しになります。

デフォルトでは変更をコミットする際に、保持していたファイルのロックが、コミット完了後自動的に開放されます。ロックを保持したままにしたい場合は、ロックを保持 チェックボックスにチェックしておきます。チェックボックスのデフォルト状態は、Subversion 設定ファイルの no_unlock オプションから取得します。Subversion 設定ファイルの編集については、「一般設定」 をご覧ください。

コミットダイアログは、関連するファイルのグループ化を助ける Subversion の変更リスト機能をサポートしています。この機能については、「変更リスト」 をご覧ください。

頻繁に変更するけれども、コミットしたくないバージョン管理下のファイルがあることがあります。これはビルドプロセスの弱点を表しています。なぜそのファイルをバージョン管理下に置いたのでしょう? テンプレートファイルを使用するべきではありませんか? しかし、時にこれはやむを得ないことがあります。古典的な理由としては、使用している IDE が、ビルドする際に必ずタイムスタンプを更新してしまうということがあります。すべてのビルド設定を含んでいるため、プロジェクトファイルをバージョン管理下に置かなければなりませんが、単にタイムスタンプを更新しただけではコミットする必要はありません。

このように、やっかいなケースを解決するのに、ignore-on-commit という変更リストを予約しておきます。この変更リストに追加されたファイルは、コミットダイアログにて自動的にチェックが外されます。それでも変更をコミットしたい場合は、コミットダイアログにて、手で選択しなければなりません。

コミットする変更を説明するログメッセージを必ず入力してください。後日プロジェクトのログメッセージを閲覧するときに、いつ、何が起きたかを確認できます。メッセージは長くても簡潔でもお好みのままですが、多くのプロジェクトで、使用する言語や、厳密なフォーマットといった記述する内容のガイドラインがあります。

メールで使用するような規約を用いて、ログメッセージの簡単な整形を行えます。text にスタイルを適用する場合、*text* で太字、_text_ で下線、^text^ で斜体を用いてください。

図4.9 コミットダイアログのスペルチェッカ

TortoiseSVN にはログメッセージを正しく書けるよう、スペルチェッカが内蔵されています。これで間違った単語を強調表示できます。提案する訂正内容にアクセスするにはコンテキストメニューを使用してください。もちろん、すべて の技術用語を知っているわけではありません。そのため正しい綴りの単語をエラーとして表示知る可能性があります。ご心配なく。コンテキストメニューから個人辞書に登録できます。

ログメッセージウィンドウは、ファイル名・関数の自動補完機構も持っています。コミットしようとしている (テキスト) ファイルから、クラス名や関数名を (ファイル名と同様に) 抽出するのに正規表現を使用します。入力している単語が (3 文字入力したり、Ctrl+Space を押して)、このリストにある単語と一致すると、名前全体を選択するドロップダウンを表示します。TortoiseSVN に渡される正規表現は、TortoiseSVN をインストールした bin フォルダで保持されます。自分で正規表現を定義し、%APPDATA%\TortoiseSVN\autolist.txt に格納しておくこともできます。もちろん自分の autolist は TortoiseSVN をアップデートしても上書きされません。正規表現になじみがなければ、http://ja.wikipedia.org/wiki/正規表現 にある導入や、http://www.regular-expressions.info/ にあるオンラインドキュメントやチュートリアルをご覧ください。

前回入力したログメッセージを再利用できます。最近のログメッセージ をクリックして、その作業コピーで入力した最新のログメッセージ一覧を表示します。保存しているログメッセージの数は、TortoiseSVN 設定ダイアログでカスタマイズできます。

保存したすべてのコミットメッセージを、TortoiseSVNの設定ダイアログの保存データ ページで消去したり、最近のログメッセージ ダイアログで Delete キーを用いて、特定の保存したログメッセージを消去できます。

チェックしたパスをログメッセージに入れたい場合、エディットコントロールで コンテキストメニュー → ファイル名のリストを貼付 を使用できます。

ログメッセージにパスを入力する別の方法は、単純にファイルリストにあるファイルを、エディットコントロールにドラッグすることです。

OK を押すと、コミットの進行状況を表示するダイアログを表示します。

図4.10 コミットの状況を表示している進行ダイアログ

進行ダイアログではコミット状態に応じて色分けで表示します。

これはデフォルトの色設定ですが、設定ダイアログで色をカスタマイズできます。詳細は 「TortoiseSVN での色設定」 をご覧ください。

競合は複数の開発者が、あるファイルの同じ行を変更した際に発生します。Subversion はプロジェクトについては何も知りませんから、開発者間の競合については解決できません。競合が報告されたら、問題のファイルを開き、<<<<<<< で始まる行を探してください。競合のある箇所は以下のようにマークがつけられています。

	<<<<<<< filename
		あなたの変更
	=======
		リポジトリからマージされたコード
	>>>>>>> revision
	

また、競合のあるファイルごとに Subversion は手元のディレクトリにファイルを 3 つ追加します。

外部マージツール・競合エディタを TortoiseSVN → 競合の編集 で起動できますし、競合の解消に他のエディタを使って手で修正もできます。コードがどうあるべきか決めて、必要な変更をしてから保存してください。

その後、TortoiseSVN → 問題の解消 コマンドを実行し、リポジトリに変更をコミットしてください。問題の解消コマンドは、実際には競合を解消しないことに注意してください。変更をコミットできるよう、filename.ext.mine ファイルや filename.ext.r* ファイルを削除するだけです。

バイナリファイルが競合した場合、Subversion はそのファイルをマージしようとしません。手元のファイルには変更を加えず (あなたが変更したままを保証)、filename.ext.r* ファイルを作ります。自分の変更を破棄し、リポジトリのバージョンにしたい場合は、「元に戻す」コマンドを使うだけです。リポジトリのバージョンを自分の変更したファイルで置き換えるのなら、「問題の解消」コマンドを行ってコミットしてください。

親フォルダを右クリックし、TortoiseSVN → 問題の解消... を選択すると、「問題の解消」コマンドを複数のファイルに実行できます。指定したフォルダにある競合したファイルがすべてダイアログに表示されます。解消するものを選択してください。

開発者がファイルやフォルダを移動・名前変更・削除したときに、別の開発者が移動・名前変更・削除を行っていたり、変更をしていたりすると、ツリーの競合が発生します。ツリーの競合はさまざまな状況で起こり得ますし、その競合を解消するにはそれぞれ異なった手順が必要です。

また、ファイルが Subversion によりローカルで削除されると、ローカルファイルシステムからも削除されるため、ツリーの競合があったとしても競合のオーバーレイを表示できず、競合を解消しようと右クリックもできません。競合の編集 オプションを用いる代わりに、変更をチェック ダイアログを使用してください。

TortoiseSVN は 変更をマージするための正しい場所を見つけるのを支援しますが、競合を整理するにはさらに作業が必要かもしれません。作業中の BASE を更新すると、常に更新時のリポジトリにある各項目のリビジョンが含まれます。更新後に変更を取り消した場合、そのリポジトリの状態へと戻り、変更開始時の状態には戻りません。

図4.12 エクスプローラのアイコンオーバーレイ表示

今、Subversion リポジトリから作業コピーにチェックアウトしたとすると、Windows エクスプローラ上でファイルのアイコンが変わっていることと思います。これこそ TortoiseSVN の評判がいい理由のひとつです。TortoiseSVN はオーバーレイアイコンと呼ばれるアイコンを、元のファイルアイコンの上に重ねて表示します。ファイルの Subversion 状態によってオーバーレイアイコンが変わります。

作業コピーにチェックアウトしたばかりのファイルには緑のチェックマークをオーバーレイします。Subversion の状態は 通常 です。

ファイルの編集をはじめるとすぐに状態が 修正 に変わり、アイコンオーバレイも赤いエクスクラメーションマークに変わります。これで最後に作業コピーを更新してからどのファイルに変更を加え、コミットする必要があるかどうか分かります。

更新中に 競合 が発生したら、黄色いエクスクラメーションマークのアイコンに変わります。

ファイルに svn:needs-lock 属性をセットしていると、そのファイルにロックをかけるまで Subversion は読み取り専用にします。この読み取り専用ファイルには、編集前にロックするまで、このオーバーレイを表示します。

ファイルをロックして Subversion 状態が 通常 ならこのアイコンが表示され、他の人がそのフィルへの変更をコミットしても良いのにロックを解放忘れをしないようにしてくれます。

バージョン管理から 削除 されるカレントフォルダ内のファイルやフォルダ、またバージョン管理が紛失したフォルダ内にあるファイルにこのアイコンがつけられます。

バージョン管理に 追加 されるファイルやフォルダには+サインがつきます。

横棒サインは、ファイルやフォルダが、バージョン管理的に 無視 されていることを示します。このオーバーレイはオプションです。

バージョン管理下にないファイルやフォルダで、無視されない場合には、このアイコンを表示します。このオーバーレイはオプションです。

実はシステムで使用できるアイコンのすべてを見ることはありません。Windows で使用できるオーバーレイの数はかなり制限されており、また TortoiseCVS の旧バージョンも使用していると、使用できるオーバーレイスロットが足らなくなります。そのため TortoiseSVN は「Good Citizen (TM)」 に挑戦し、オーバーレイを他のアプリケーションが使用できるように制限しているのです。

現在では、たくさんの Tortoise クライアントが存在する (TortoiseCVS, TortoiseHG, ...) ため、アイコンの限界は現実の問題になっています。これに対処するため、TortoiseSVN プロジェクトは Tortoise クライアントで共通に使用できるように、DLL で読み込む共有アイコンセットを導入しました。もう統合されているかを、各クライアントのプロバイダでチェックしてみてください。:-)

Subversion の状態に対応するアイコンオーバーレイの付き方や、その他の技術詳細は、「アイコンオーバーレイ」 をご覧ください。

アイコンオーバーレイと同様 (またそれ以上) の情報を、Windows エクスプローラの詳細ビューに追加する列で表示できます。

単に列の見出しを右クリックして出てくるコンテキストメニューの、その他... を選んでください。「詳細ビュー」 の列とその順番を設定するダイアログが表示されます。SVN で始まる項目が出てくるまでスクロールしてください。表示したい項目にチェックをつけ、OK を押してダイアログを閉じてください。元々表示していた項目の右に列が追加されているはずです。お好みに応じて、ドラッグ&ドロップで順番を変えたり大きさを変更してください。

図4.13 変更をチェック

あなたがどのファイルを変更したか、また他の人がどのファイルを変更しコミットしたかを知ることは非常に有用です。これには TortoiseSVN → 変更をチェック... コマンドが役に立ちます。このダイアログは作業コピー内で何らかの変更をした全てのファイルを表示し、バージョン管理外のファイルも指定すれば同様に表示します。

リポジトリをチェック をクリックすると、リポジトリの変更点も参照できます。競合が起こりそうな場合、更新前にこれで変更点を確認できます。リポジトリの全てのフォルダを更新しないで、選択したファイルのみ更新することもできます。デフォルトでは、リポジトリをチェック ボタンは、作業コピーに対してチェックアウトした深さまでしか、リモートの状態を取得しません。リポジトリ内のファイル・フォルダすべてを、チェックアウトしていなくても見たい場合は、Shift キーを押しながら、リポジトリをチェック ボタンをクリックしてください。

このダイアログでは、状態を色分けで表示します。

これはデフォルトの色設定ですが、設定ダイアログで色をカスタマイズできます。詳細は 「TortoiseSVN での色設定」 をご覧ください。

別のリポジトリパスに切り替えた項目には、(s) マークが付きます。何かを切り替えてブランチで作業した後、トランクに戻すのを忘れている可能性もあります。これは警告マークです!

このダイアログのコンテキストメニューから、変更点の差分を取れます。あなた が行った手元の変更をチェックするのには、コンテキストメニュー → Base と比較 を使用してください。他の人が行ったリポジトリへの変更は、コンテキストメニュー → Unified Diff 形式で差分を表示 を使用してください。

個々のファイルhwの変更を元に戻すこともできます。誤ってファイルを消してしまった場合には、紛失 と表示されますし、修復するのに 元に戻す ことができます。

バージョン管理外のファイルや無視ファイルは、コンテキストメニュー → 削除 でゴミ箱に送れます。完全に (ゴミ箱経由なしで) ファイルを削除するには、Shift キーを押したまま 削除 をクリックしてください。

ファイルの詳細を調べたければ、ここからテキストエディタや IDE のような、別のアプリケーションにドラッグできます。

下のペインに表示された列は、カスタマイズできます。列見出しの上で 右クリック すると、表示する列を選択するコンテキストメニューを表示します。また、列の境界上にマウスを持っていくとドラッグハンドルを表示し、列幅を変更できます。以上のカスタマイズは保存されるので、次回以降も同じ列見出しになります。

関連のない複数のタスクを一度に処理する場合、変更リストにあるファイルをまとめて扱うこともできます。詳細情報は 「変更リスト」 をご覧ください。

ダイアログの下部に、作業コピーで使われている、リポジトリリビジョンの範囲の概要を表示しています。これは 更新 リビジョンではなく コミット リビジョンで、ファイルが更新されたリビジョンではなく、ファイルが最後にコミットされた時のリビジョン範囲を表しています。リビジョン範囲は作業コピー全体ではなく、表示されている項目のみに対して表していることに注意してください。作業コピー全体に対してこの情報を表示する場合は、未変更ファイルを表示 チェックボックスにチェックを入れなければなりません。

時にはどんな変更をしたのかファイルの中を見たくなるでしょう。それには、変更のあるファイルを選択して、TortoiseSVN のコンテキストメニューから 差分 を選択するとできます。これで外部差分ビューアを起動し、現在のファイルとチェックアウト・更新を行った直後のコピー (BASE リビジョン) とを比較できます。

図4.15 リビジョンログダイアログ

いろいろな場所からログダイアログを表示できます。

リポジトリが利用できない場合、「オフラインモード」 で説明する、オフラインにしますか? ダイアログを目にすることになります。

上部ペインには、そのリビジョンで何が行われたかをまとめた アクション 列があります。4 つのアイコンが、それぞれ 1 列ずつ表示されます。

ファイルやディレクトリにそのリビジョンで変更がある場合、変更 アイコンが第一列に表示されます。

ファイルやディレクトリがそのリビジョンで追加された場合、追加 アイコンが第二列に表示されます。

ファイルやフォルダがそのリビジョンで削除された場合、削除 アイコンが第三列に表示されます。

ファイルやフォルダがそのリビジョンで置換された場合、置換 アイコンが第四列に表示されます。

図4.16 リビジョンログダイアログ上部ペインのコンテキストメニュー

ログダイアログの上部ペインには、より詳細な情報にアクセスするコンテキストメニューがあります。このメニューにはファイルでしか現れないものと、フォルダにしか現れないものがあります。

図4.17 2 リビジョン選択時の上部ペインコンテキストメニュー

同時に 2 つのリビジョンを (Ctrl を押しながら) 選択すると、コンテキストメニューの内容が変わり、以下の機能だけになります。

2 つ以上のリビジョンを選択 (通常 Ctrl や Shift を押しながら選択) すると、 コンテキストメニューにリビジョンの範囲を指定してすべての変更を取り消す項目が現れます。これがリビジョンのグループを一度に元に戻す、簡単な方法です。

また、前述のとおり、選択したリビジョンを別の作業コピーにマージできます。

選択したすべてのリビジョンが、同じ作者のものであれば、すべてのリビジョンの作者を一気に編集できます。

図4.18 ログダイアログ下部ペインのコンテキストメニュー

ログダイアログの下部ペインにもコンテキストメニューがあり、以下を行えます。

ログダイアログは以下のような理由で、すべての変更を常に表示するわけではありません。

ログメッセージをもっと見たい場合は、次の 100 をクリックして次の 100 件のログメッセージを取得してください。必要なだけ繰り返せます。

このボタンの隣に、前回使用したオプションを記憶している、マルチファンクションボタンがあります。三角をクリックすると他のオプションを指定できます。

リビジョンの範囲を指定する場合、範囲を表示 ... を使用してください。ダイアログが表示されるので、開始リビジョンと終了リビジョンを指定してください。

最新リビジョンからリビジョン 1 へ すべての ログメッセージが見たければ、すべて表示 を押してください。

ログダイアログには、現在の作業コピーのリビジョンではなく、HEAD からログを表示するため、作業コピーがまだ取得していない内容のログメッセージを表示することが、しばしばあります。これを明確にするために、作業コピーが持つリビジョンに一致するコミットメッセージを太字で表示します。

フォルダのリビジョンを表示する際、強調されたリビジョンは、そのフォルダの近辺にある最大のリビジョンになります。これには作業コピーのクロールが必要です。これは大きな作業コピーでは、遅い処理になり、クロールが完了するまでログメッセージが表示されません。この機能を無効にしたり、制限したりしたい場合は、「レジストリの設定」 で説明するように、レジストリキー HKCU\Software\TortoiseSVN\RecursiveLogRev をセットしてください。

Subversion 1.5 以降では、属性を利用してマージ情報を保持しています。これにより、マージでの変更点の詳細な履歴を得られます。例えば、ブランチで新機能を開発し、ブランチをトランクにマージした場合、たとえブランチでの開発で 1000 コミットしたとしても、トランクでのその機能の開発には、1 コミットしかしていないことになってしまいます。

図4.19 マージ追跡リビジョンを表示したログダイアログ

コミットにマージが含まれるリビジョンの詳細を見る場合、マージされたリビジョンを含める チェックボックスを使用してください。これによりログメッセージを再取得しますが、マージされたリビジョン由来のログメッセージの挿入も行います。マージされたリビジョンは、別ツリーで変更されているので、灰色で表示します。

もちろん、マージは決して単純ではありません! ブランチでの機能開発中、メインラインコードと同期を取り続けるために、トランクからたびたび行わなければならないでしょう。そのため、ブランチのマージ履歴には、別レイヤのマージ履歴が含まれていることでしょう。ログダイアログでは、異なるレイヤをインデントレベルで表します。

リビジョン属性は、各項目の Subversion 属性とはまったく違います。リビジョン属性は、ログメッセージやコミット日時、コミットした人 (作者) といった、リポジトリの特定のリビジョン番号に関連する説明的な項目です。

時には、一度入力したログメッセージを変更したいこともあるでしょう。綴り間違いがあったり、またメッセージを改善、その他の理由で変更したくなるかもしれません。また、コミットした作者を変更した区なるかもしれません。認証のセットアップ方法を忘れてしまったとか……

Subversion では、必要に応じてリビジョン属性をいつでも変更できます。しかし、その変更を元に戻せない (この変更はバージョン管理外になります) ので、デフォルトではこの機能は無効になっています。有効にするには、pre-revprop-change フックをセットアップしなければなりません。この手順の詳細については、Subversion Book の Hook Scripts をご覧ください。(訳注 日本語では フックスクリプトをご覧ください) Windows マシンでのフックの実装については、「サーバ側フックスクリプト」 をご覧ください。

一度、必要なフックをサーバにセットアップしてしまえば、任意のリビジョンに対して、作者とログメッセージ (もしくはその他のリビジョン属性) を変更できます。ログダイアログの上部ペインからコンテキストメニューを使用してください。中央ペインのコンテキストメニューを使用しても、ログメッセージを編集できます。

興味あるログメッセージを表示するよう限定するなら、何百もあるリストをスクロールするよりも、ログダイアログの上端にあるフィルタコントロールを使用したほうがいいです。開始終了日のコントロールで日付の範囲をしてください。検索ボックスで入力した部分文字列を持つメッセージだけを表示できます。

検索アイコンをクリックして、検索したい情報を選択してください。また正規表現モードも選択できます。通常はシンプルなテキスト検索があれば十分でしょうが、もっと柔軟な検索語句を指定したい場合、正規表現を使用できます。ボックスの上にマウスを持っていくと、正規表現の使い方のヒントをツールチップで表示します。オンラインドキュメントやチュートリアルも http://www.regular-expressions.info/ にあります。フィルタは、フィルタ文字列がログエントリとマッチするかどうかをチェックし、フィルタ文字列と マッチ したエントリのみを表示します。

フィルタ文字列に一致しないログエントリを表示するようフィルタをかけるには、文字列をエクスクラメーションマーク ('!') で始めてください。例えば、フィルタ文字列 !username は username がコミットしていないエントリのみを表示します。

このフィルタは、すでに取得したメッセージにのみ効果があることに注意してください。リポジトリからメッセージをダウンロードするような動作はしません。

また、下部ペインのパス名を、変更されたパスで無関係なものは表示しない チェックボックスでフィルタできます。関係するパスは、ログを表示するのに使用するパスを含んでいます。フォルダのログを取得する場合、そのフォルダ以下のログを取得することを意味しています。ファイルに対しては、その 1 ファイルのみであることを意味しています。チェックボックスは 3 状態をとります。すべてのパスを表示する、または無関係なものを灰色にする、無関係なものを完全に隠すです。

時には運用手順として、ログメッセージを特定のフォーマットにする必要があるかもしれません。これは変更点を説明するテキストが、上部ペインに表示する短縮サマリに表示されないということです。tsvn:logsummary 属性を使用して、上部ペインに表示しているログメッセージの一部を抽出できます。この属性の使い方は、「TortoiseSVN のプロジェクト属性」 をご覧ください。

ログダイアログの 統計 ボタンはリビジョンについての興味深い情報を表示します。作業者が何人いるのか、コミットは何回行われているのか、週ごとの進行、その他といった情報です。これで、誰ががんばり屋で誰がなまけ者か一目で分かります。;-)

「作者によるコミット」ページ

図4.20 「作者によるコミット」ヒストグラム

このグラフは、プロジェクト内のどのユーザがアクティブかを、単純なヒストグラム、積み重ねヒストグラム、円グラフで表します。

図4.21 「作者によるコミット」円グラフ

少数の主要な作者と、多数のこまかな協力者がいるところでは、小さなセグメントが多くなり、グラフが読みにくくなります。グラフの下にあるスライダを使用してしきい値 (全コミットにおけるパーセンテージ) を設定し、活動状況がしきい値以下の人を その他 カテゴリにします。

「日毎のコミット数」ページ

図4.22 「日毎のコミット数」グラフ

このページでは、コミット回数 と 作者から、プロジェクトの活動状況をグラフで表示します。これによりプロジェクトがいつ活動していたか、そのとき誰が作業したかといった判断材料になるでしょう。

複数の作者がいる場合、グラフの線がたくさん表示されます。ここで 2 通りの表示があります。通常 は、作者の活動状況ごとに表示し、積み重ね は、作者の活動状況を積み重ねて表示します。後者では、グラフを読みやすくするため、線が交差するのを避けますが、作者ごとに表示した方が見やすいでしょう。

デフォルトでは、分析する際、ユーザ名の大文字と小文字を区別します。そのため、PeterEgan と PeteRegan というユーザは別人として扱われます。しかし多くの場合、ユーザ名の大文字と小文字を区別しておらず、時々混同して入力されます。つまり、DavidMorgan と davidmorgan を同一として扱うということです。作者名の大文字／小文字を区別しない チェックボックスを使用して、どのように扱うかを制御してください。

この統計はログダイアログと同じ期間をカバーするのに注意してください。1 リビジョンしか表示していないときには、統計には大した情報は現れません。

図4.23 オフライン化ダイアログ

サーバに到達せず、ログキャッシュを有効にしている場合、ログダイアログやリビジョングラフはオフラインモードで利用できます。これはキャッシュからのデータを使用し、作業を継続できますが、おそらく最新でも完全でもありません。

ここでは以下の 3 種のオプションがあります。

デフォルトに設定する チェックボックスは、このダイアログを再度表示しないようにし、選択した内容を常に使用します。ここで設定したとしても、TortoiseSVN → Settings で、デフォルト値の変更 (削除) が行えます。

新しいログメッセージを取得するためサーバを再チェックする場合、単純に F5 で表示を更新できます。ログキャッシュを使用する場合 (デフォルトで有効)、新しいログメッセージがあるかリポジトリをチェックし、新しいもののみを取得します。ログキャッシュがオフラインモードだった場合、オンラインモードにしようともします。

ログキャッシュを使用しており、メッセージの内容や作者を変更したい場合、Shift-F5 や Ctrl-F5 で表示しているメッセージをサーバから再取得し、ログキャッシュを更新できます。これは現在表示しているメッセージにしか効果はなく、そのリポジトリのキャッシュ全体が無効になるわけではないことに注意してください。

サードパーティの diff ツールを設定している場合、差分コマンドを選択する際にShift を押して代替ツールを使用できます。その他の diff ツールの設定については、「外部プログラムの設定」 をご覧ください。

プロジェクトを続けていくと、時には改行コードを CRLF から LF に変更したり、セクションのインデントを変更したりすることがあります。不幸なことに、かなりの行を変更しなければなりませんが、コードの意味には変更はありません。以下のオプションでは、比較や差分適用の際の変更点のとり方を管理します。この設定は、マージ ダイアログや 注釈履歴 ダイアログに対して、TortoiseMerge の設定と同様に作用します。

改行コードを無視する 改行コードしか差異のない変更は無視します。

空白を比較する インデントや行内の空白の追加・削除を変更点に含みます。

空白の変更を無視する 空白の数や種類しか差異のない変更は無視します。例: インデントの変更やタブからスペースへの変更など。以前何も無かった箇所への空白の追加や、空白の削除は、変更として表示します。

すべて空白を無視する 空白のみの変更をすべて無視します。

当然、内容の変更のある行は、常に差分に含めます。

図4.24 リビジョンの比較ダイアログ

リポジトリブラウザにある 2 つのツリーを選択したり、ログダイアログにあるフォルダのの 2 つのリビジョンを選択すると、コンテキストメニュー → リビジョンを比較 を行えます。

このダイアログは、変更されたすべてのファイルを表示し、コンテキストメニューから個々に比較・注釈履歴取得を行えます。

変更したツリー をエクスポートできます。これは、他の誰かがプロジェクトのツリー構造を必要しているけれども、変更したファイルのみ必要としている場合に便利です。この操作は変更したファイルにのみ有効ですので、興味のあるファイル (たいていすべて) を選択する必要があります。その後、コンテキストメニュー → 選択をエクスポート... としてください。変更したツリーを保存する場所を指定することになります。

また、コンテキストメニュー → 選択ファイルのリストを保存... として、変更したファイルのリストもエクスポートできます。

ファイルの一覧 と 操作 (変更・追加・削除) をエクスポートする場合、コンテキストメニュー → 選択範囲をクリップボードにコピー を用いて行えます。

最上部のボタンは、比較の方向を変更します。AからBへの変更点を表示でき、希望によりBからAにでも表示できます。

リビジョン番号があるボタンは、リビジョン範囲を変えるのに使用できます。範囲を変える際、2 つのリビジョン間の差異に自動で更新します。

ファイル名の一覧が非常に長い場合、検索ボックスを使用して、特定のテキストを含むファイル名のみを抽出できます。シンプルなテキスト検索を行いますので、C のソースファイルを指定したい場合は、*.c ではなく .c としてください。

テキストファイルの差分を取るツールは (TortoiseMerge を含め) たくさんありますが、画像ファイルにどんな変更が加えられたかを知るツールも欲していました。ですから TortoiseIDiff を作りました。

図4.25 画像差分ビューア

いずれかのよくある画像フォーマットで TortoiseSVN → Diffとすると、画像の差分を取る TortoiseIDiff を起動します。デフォルトでは画像を横に並べて表示しますが、表示メニューやツールバーで上下に表示したり、お好みなら画像を重ねて表示し、ライトボックスを使っているかのように見せかけることもできます。

当然、画像をズームイン・ズームアウトしたり、平行移動もできます。単に左ドラッグでも、イメージを平行移動できます。Link images together オプションを選択しておくと、視点変更コントロール (スクロールバー、マウスホイール) は両方の画像をリンクして動かします。

画像情報ボックスには、ピクセル単位のサイズや、解像度、色深度など、画像ファイルの詳細を表示します。このボックスが邪魔になるなら、表示 → 画像情報 で隠すことができます。これと同じ情報は、画像タイトルバーの上にマウスを持っていくと表示されます。

イメージをオーバーレイしている場合、上部のスライダで、画像の相対的な輝度 (アルファブレンディング) を制御できます。スライダ上のクリックした箇所で透明度を直接制御できますし、スライダをドラッグしてインタラクティブに透明度を変更できます。Ctrl+Shift-ホイール でも透明度を変更できます。

スライダの上にあるボタンで透明度を 0% と 100% で切り替えられます。また、ボタンをダブルクリックすると、もう一度ボタンをクリックするまで、秒ごとに透明度を自動で交互に切り替えます。複数の小さな変更を見るのに便利でしょう。

ブレンディングではなく差分を確認したい場合もあります。各リビジョンにプリント基板の画像イメージがあり、どのトラックが変更されたかを見たい場合などです。アルファブレンディングモードを無効にすると、各ピクセルの色を XOR して差分を表示します。変更のない部分は真っ白になり、変更点だけ色がつきます。

私たちが提供するツールがニーズに合わなかったら、たくさんあるオープンソース・商用のツールの中から、利用できるものを試してみてください。みんなそれぞれいいところがありますし、この一覧は完全なものではありません。が、検討するかもしれないものを以下に挙げます。

以上のツールを使用するよう TortoiseSVN をセットアップするには 「外部プログラムの設定」 をご覧ください。

Subversion の無視パターンは、ファイル名展開を使用できます。これは本来 Unix でファイルを指定するのにメタキャラクタをワイルドカードとして使用するテクニックです。以下の文字が特別な意味を持ちます。

パターンマッチは大文字小文字を区別しますが、これは Windows で問題の原因になるかもしれません。両方指定すれば、強制的に大文字小文字を区別しないようにできます。例えば、大文字小文字に関わらず *.tmp を無視するには、*.[Tt][Mm][Pp] といったパターンで指定できます。

展開の公式定義が必要な場合、シェルコマンド言語の IEEE 仕様書 Pattern Matching Notation で手に入ります。

subversionから、ファイルやフォルダを削除するには、TortoiseSVN → 削除 としてください。

ファイルを TortoiseSVN → 削除 すると、作業コピーからすぐに削除し、次のコミットでリポジトリから削除するようにマークを付けます。ファイルの親フォルダには 「削除」 オーバーレイアイコンを表示します。変更をコミットする前なら、親フォルダで TortoiseSVN → 元に戻す で元に戻せます。

フォルダを TortoiseSVN → 削除 すると、作業コピーには残りますが、オーバーレイアイコンが変わり削除のマークが付きます。変更をコミットする前なら、そのフォルダで TortoiseSVN → 元に戻す で元に戻せます。この違いは、Subversion の部分によるもので、TortoiseSVN によるものではありません。

リポジトリから削除したい、でもバージョン管理外のファイル・フォルダとして保持しておきたい場合には、拡張コンテキストメニュー → 削除 - ローカルファイルを保持 をお使いください。エクスプローラのリストペイン (右ペイン) で Shift キーを押したまま、項目を右クリックすると、拡張コンテキストメニューを表示します。

TortoiseSVN コンテキストメニューを使用しないで、ファイルをエクスプローラで削除した場合、コミットダイアログにそのファイルを表示し、コミットの前にバージョン管理から削除するかどうか確認することになります。しかし、作業コピーを更新する場合、Subversion は紛失ファイルを特定し、リポジトリから最新のファイルを取得して置き換えます。バージョン管理下のファイルを削除する必要がある場合は、常に TortoiseSVN → 削除 を使用するようにしてください。そうすると Subversion がファイルを本当に削除したいのかどうか推測する必要がなくなります。

TortoiseSVN コンテキストメニューを使用しないで、フォルダをエクスプローラで削除した場合、作業コピーを破損してしまいコミットできなくなります。作業コピーを更新すると、Subversion はリポジトリから最新のフォルダを取得し、紛失したフォルダと置き換えます。そのため、フォルダを削除する正しい方法は、TortoiseSVN → 削除 を使用することです。

ファイル・フォルダの名前の変更をその場で行う場合、コンテキストメニュー → 名前の変更... を使用してください。新しい項目名を入力すると完了します。

別のサブフォルダへなど、作業コピー内に移動する場合、右ドラッグ & ドロップハンドラを以下のように使用してください。

また、リポジトリブラウザを用いて、項目を移動できます。詳細は 「リポジトリブラウザ」 をご覧ください。

Windows 上の Subversion で、ファイル名を文字の大小のみの変更はやりにくいです。変更中の短時間でも、両方のファイル名が同時に存在してしまうためです。Windows は、文字の大小を区別しないファイルシステムを使用しており、通常の「名前の変更」コマンドは使用できません。

幸い、ログの履歴を失わずにファイルの名前を変更する、(少なくとも) 2 つの有効な解決法があります。重要なのは Subversion で名前を変更することです。単にエクスプローラで名前を変更すると、作業コピーが壊れてしまいます!

解決法 A) (お勧め)

解決法 B)

リポジトリ内に、文字の大小のみが異なる同じ名前のファイル (例: TEST.TXT と test.txt) がある場合、Windows のクライアントで、親ディレクトリの更新・チェックアウトができなくなります。Subversion は文字の大小を区別していますが、Windows はそうではないからです。

これは 2 人の人が別々の作業コピーから、同じ名前で文字の大小のみ異なるファイルをコミットした場合に発生します。また Linux のような、文字の大小を区別するファイルシステムを使用するシステムからコミットした場合も、発生します。

この場合どちらかを残し、一方をリポジトリから削除 (または名前変更) するよう決めなければなりません。

時に、親切な IDE がリファクタリングの一環でファイルの名前変更を行います。そしてもちろん Subversion に通知しません。変更をコミットすると、Subversion には古いファイル名を紛失ファイル、新しいファイル名をバージョン管理外のファイルとして見えることになります。新しいファイルを追加することもできますが、Subversion にはそのファイルの関連が分かりませんから、追跡履歴を失うことになります。

もっと良い方法は、Subversion に実際には名前変更であったと通知することです。これはコミット ダイアログと 変更をチェック ダイアログで行えます。単に古い名前 (紛失) と新しい名前 (バージョン管理外) を選択し、コンテキストメニュー → 移動を修復 を使用して、2 つのファイルが名前の変更であったと通知します。

通常、生成した全ファイルといった無視リストは、Subversion が無視します。しかし、もしクリーンビルドを提供するため、無視されるファイルをすべてクリアするとしたらどうでしょうか? 通常、makefile を設定しているでしょうが、makefile のデバッグやビルドシステムを変更する際に、デッキをクリアする方法があると便利です。

TortoiseSVN はそのような場合に 拡張コンテキストメニュー → バージョン管理外のファイルを削除する... を使用するという選択肢を提供しています。エクスプローラのリストペイン (右ペイン) で Shift キーを押したまま、フォルダを右クリックすると、拡張コンテキストメニューを表示します。これにより作業コピーにあるバージョン管理外ファイルの一覧ダイアログが現れます。削除するファイルを選択状態・未選択状態にできます。

そのようなファイルを削除した際、ゴミ箱を使用していますので、もし間違ってバージョン管理化におくはずのファイルを削除してしまっても、元に戻せます。

図4.32 Subversion の属性ページ

Windows のプロパティダイアログから、Subversion の属性を確認・設定できますが、さらに TortoiseSVN → 属性 や コンテキストメニュー → 属性 からの TortoiseSVN の状態リストでも確認できます。

自分で定義した属性の他、Subversion で特別な意味のある属性も追加できます。これは svn: で始まります。svn:externals も、そのような属性です。「外部項目」 で外部参照の説明をしていますのでご覧ください。

Subversion の属性に関する詳細情報は、Special Properties をご覧ください。

属性の追加と編集

図4.33 属性の追加

新しい属性をセットするには、まず 追加... をクリックしてください。必要な属性名をコンボボックスから選択・入力し、下のテキストボックスに値を入力してください。無視リストのような複数の値を持つ属性は、複数行で入力してください。OK をクリックして、この属性をリストに追加してください。

一度にたくさんの項目に対して属性を設定する場合は、エクスプローラでファイル/フォルダを選択し、コンテキストメニュー → 属性 を選択してください。

現在のフォルダ以下にある すべての ファイルやフォルダに対して属性を適用する場合、再帰 チェックボックスをチェックしてください。

svn:needs-lock のようないくつかの属性は、ファイルにしか適用できず、フォルダのドロップダウンリストには属性名が表示されません。その階層内すべてのファイルにそういった属性を適用できますが、属性名は自分で入力しなければなりません。

既存の属性を編集する場合、属性の一覧から編集する属性を選択し、編集... をクリックしてください。

既存の属性を削除したい場合、属性の一覧から削除する属性を選択し、削除 をクリックしてください。

svn:externals 属性は、同じリポジトリからでも完全に異なるリポジトリからでも、他のプロジェクトを取得するのに使用できます。詳細は 「外部項目」 をご覧ください。

TortoiseSVN は自身が持つ特殊な属性をいくつか持っています。これは tsvn: で始まります。

tsvn: 属性のいくつかは true/false 値をとります。TortoiseSVN は yes を true と同義に、no を false と同義に解釈します。

TortoiseSVN はいくつかのバグ追跡ツールと統合できます。このとき bugtraq: で始まるプロジェクト属性を使用します。詳細情報は 「バグ追跡システム / 課題追跡システムとの統合」 をご覧ください。

TortoiseSVN は、webviewer: で始まるプロジェクト属性を使用して、いくつかの Web ベースリポジトリブラウザとも統合できます。詳細は 「Web ベースリポジトリビューアとの統合」 をご覧ください。

TortoiseSVN で新しいサブフォルダを作成する際、親フォルダに設定されているプロジェクト属性は、新しいサブフォルダに自動的に追加されます。

では /project1 の作業コピーを D:\dev\project1 にチェックアウトしましょう。D:\dev\project1 フォルダを選択し、右クリック してコンテキストメニューのWindows メニュー → プロパティ+追加...+設定

URL は適切にエスケープされねばならず、そうでなければ動作しません。例えば、前述の 2 番目の例にあるように、各空白を %20 に置換しなければなりません。

ローカルのパスに空白や特殊文字を使用したい場合、二重引用符で囲ったり、Unix シェル形式のエスケープ文字 \ (バックスラッシュ) を特殊文字の前に置いてください。もちろんこれは、パス区切り文字に / (スラッシュ) を使わなければならない、ということでもあります。この挙動は Subversion 1.6 の新機能で、それ以前のクライアントでは動作しないことに注意してください。

外部プロジェクトが同じリポジトリにある場合、メインプロジェクトをコミットしたときに、外部プロジェクトに行った変更もコミットされてしまいます。

外部プロジェクトが別のリポジトリにある場合、メインプロジェクトのコミット時に、外部プロジェクトに対する変更は通知されますが、別々にコミットする必要があります。

svn:externals の定義に絶対 URL を使用し、作業コピーを再配置しなければならない (つまり、リポジトリの URL を変更する) 場合、外部参照は変化せず、もう動作しないかも知れません。

このような問題を避けるため、Subversion クライアントバージョン 1.5 以降では、相対外部参照 URL をサポートします。相対 URL を指定する 4 つの異なる方法をサポートしています。以下の例では、2 つのリポジトリ (http://example.com/svn/repos-1 と http://example.com/svn/repos-2) があると仮定します。C:\Working に http://example.com/svn/repos-1/project/trunk のチェックアウトがあり、トランクに svn:externals プロパティをセットしています。

必要であれば、URL の後にペグリビジョンも指定できます。例えば http://sounds.red-bean.com/repos@19 といった形です。

TortoiseSVN が属性をどのように扱うかについての詳細な情報は、「プロジェクト設定」 を参照してください。

共通サブプロジェクトへの他のアクセス方法については、「共通のサブプロジェクトを含める」 を参照してください。

Subversion 1.6 では、フォルダと同じ文法を用いて、単一ファイルの外部項目を作業コピーに追加できます。しかし、いくつか制限事項があります。

外部ファイルの挙動は、あらゆる点でその他のバージョン管理下のファイルと同等ですが、通常のコマンドでは、移動・削除ができません。代わりに svn:externals 属性を変更しなければなりません。

プロジェクトをお勧めディレクトリ構成でインポートしているなら、ブランチ・タグバージョンを作成するにはとてもシンプルです。

図4.34 ブランチ・タグダイアログ

ブランチやタグにコピーしたい作業コピーのフォルダを選択してから、TortoiseSVN → 分岐/タグ... コマンドを選択してください。

新しいブランチのデフォルトの先 URL は、作業コピーの基準になった元 URL になっています。ブランチ・タグの新しいパスに URL を編集する必要があるでしょう。つまり、

    http://svn.collab.net/repos/ProjectName/trunk

の代わりに、

    http://svn.collab.net/repos/ProjectName/tags/Release_1.10

のようにするということです。前回使用した命名規則を思い出せなければ、既存のリポジトリ構造を見るのに、リポジトリブラウザを開く右のボタンを押してください。

では、コピー元を選択してください、ここでは 3 種類の選択肢があります。

新しく作成したブランチに、自動的に作業コピーを切り替えたい場合、新しい分岐／タグへ作業コピーを切り替え チェックボックスを使用してください。しかしそうするには、まず作業コピーに変更が含まれていてはいけません。もし含まれていると、切り替えたときにブランチの作業コピーに変更点がマージされていまいます。

リポジトリに新しいコピーをコミットするのに OK を押してください。ログメッセージを書くのを忘れないでください。コピーは リポジトリの中 で行われることに注意してください。

作業コピーを新しく作成したブランチに切り替えなければ、ブランチやタグを作成しても、作業コピーには影響を 与えない ことに注意してください。作業コピーからブランチを作成したとしても、その変更はトランクではなく新しいブランチにコミットされます。そのため、作業コピーのマークは、変更されたままになっているかもしれません。

……これは (それほどじゃないですが) 問題です。チェックアウトは、リポジトリの指定したブランチから作業コピーへすべてダウンロードしますが、TortoiseSVN → 切り替え... は変更のあったデータのみを作業コピーに転送します。ネットワーク負荷をとるか、忍耐力をとるかですね。:-)

新しく生成したブランチやタグで作業するには、いくつかの方法があります。以下のように行ってください。

図4.35 切り替えダイアログ

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

図4.36 マージウィザード - リビジョン範囲の選択

元: フィールドには、作業コピーに取り込みたい変更があるブランチやタグのフォルダの URL をすべて入力してください。... をクリックしてリポジトリを閲覧し望みのブランチを探すこともできます。このブランチから以前マージしていれば、以前に使用した URL の履歴のドロップダウンリストを使うだけです。

マージするリビジョンの範囲 フィールドに、マージするリビジョンのリストを入力してください。ここではリビジョン一つ、カンマで区切ったリビジョンの指定、ダッシュでつないだリビジョンの範囲と以上の組み合わせが利用できます。

必要なリビジョンの範囲を選択する最も簡単な方法は、ログを表示 をクリックして、最近の変更点一覧をログメッセージと共に表示することです。単一リビジョンからマージしたい場合は、そのリビジョンを選択するだけです。複数のリビジョンからマージしたい場合は、その範囲を (通常 Shift キーを押しながら) 選択してください。OK をクリックすると、マージするリビジョン番号のリストに入力されます。

すでにコミットしてしまった変更を取り消して、作業コピーを元に戻すようにマージする場合、元に戻すリビジョンを選択して、逆マージ チェックボックスを必ずチェックしてください。

このブランチからの変更をすでにマージしてある場合、うまくいけば変更をコミットしたときのメッセージに、マージした最後のリビジョンを記録してあるかもしれません。この場合、作業コピーのログメッセージを追跡するのに ログを表示 を使用できます。リビジョンをチェンジセットとして考えているのを思い出し、前回のマージの終点を今回のマージの始点をしてください。たとえば、前回リビジョン 37 から 39 までマージした場合、今回のマージの始点をリビジョン 40 にしてください。

Subversion のマージ追跡機能を使用する場合、どのリビジョンをすでにマージしたかを覚えておく必要はありません。Subversion が記録しています。リビジョン範囲をからのままにしておくと、まだマージしていないリビジョンすべてが対象になります。詳細は 「マージ追跡」 をご覧ください。

他の人が変更をコミットしている場合、HEAD リビジョンを使用するのは注意してください。最後の更新のあとに誰かがコミットを行っており、想定しているリビジョンを指していないかもしれません。

次 をクリックして 「マージオプション」 に進んでください。

図4.37 マージウイザード - マージの再統合

機能ブランチをトランクにマージするには、トランクの作業コピーから、マージウィザードを起動しなければなりません。

元 URL: フィールドには、マージして戻したいブランチの、完全なフォルダ URL を入力してください。... をクリックして、リポジトリの参照もできます。

再統合マージを適用するには、いくつか条件があります。まず、サーバがマージ追跡をサポートしていなければなりません。作業コピーの深さに制限があってはなりません (まばらなチェックアウトではならない)。ローカルの変更や切り替わった項目、最新以外のリビジョンに更新された項目があってはなりません。ブランチでの開発中にトランクに行われた変更は、ブランチをまたがってマージされなければなりません (もしくはマージするとマークされなければなりません)。マージするリビジョンの範囲は自動的に計算されます。

図4.38 マージウィザード - ツリーのマージ

機能ブランチをトランクにマージするために、この方法を使用する場合、トランクの作業コピーでマージウィザードを起動する必要があります。

元: フィールドには、トランク の完全なフォルダ URL を入力してください。間違っているように思われるかもしれませんが、トランクが、ブランチの変更を追加する起点となることを思い出してください。... をクリックして、リポジトリの参照もできます。

先: フィールドに、機能ブランチの URL を入力してください。

元 リビジョン フィールドと 先 リビジョン フィールドの両方に、同期をとりたい 2 つのツリーの最新リビジョン番号を入力してください。他の誰もコミットしていないという確認が取れているのなら、どちらも HEAD リビジョンを使用できます。同期をとってから、誰かがコミットする機会があったのなら、最近のコミットの内容を失わないように、リビジョン番号を指定してください。

リビジョンを選択するには ログを表示 も使用できます。

ウィザードのこのページでは、マージの実行前に、さらにオプションの指定ができます。ほとんどの場合デフォルトの設定使用するだけでしょう。

また、マージする深度も指定できます。これは、作業コピー内をどの程度深くたどってマージを行うべきかということです。深度については 「チェックアウトの深度」 で説明しています。デフォルトの深度は 作業コピー で、既存の深度をそのまま使用します。

大抵、共通の系統が関係する変更点をマージするように、ファイルの履歴を考慮に入れたいと思うでしょう。時には、おそらく関係する (しかしリポジトリにない) ファイルのマージが必要となります。例えば、サードパーティ製ライブラリのバージョン 1 とバージョン 2 を、それぞれ別のディレクトリにインポートしたとします。これは論理的には関係ありますが、Subversion は tarball をインポートしたとしか見えないので、関係があるとはわかりません。この 2 つのツリーの違いをマージしようとするなら、完全に追加してから完全に除去することになります。Subversion が履歴ベース差分ではなくパスベース差分を使用するようにするには、系統情報の無視 チェックボックスをチェックしてください。このトピックの詳細は、Subversion book の Noticing or Ignoring Ancestry をご覧ください。

改行コードや空白の変更に対する扱い方を指定できます。このオプションについては 「改行コードと空白のオプション」 で説明しています。デフォルトの振る舞いは、空白や改行コードの差異も実際の変更としてマージします。

マージ追跡を使用していて、実際にはマージせずにマージしたという印をつけたい場合、マージのみを記録する チェックボックスをチェックしてください。そうする理由として二つ考えられます。一つは、マージそのものがマージアルゴリズムに対して複雑すぎ、手でコードを修正した後、マージアルゴリズムが行うようにマージにより変更したという印をつけたい場合です。もう一つは、特定のリビジョンがマージされるのを防ぐ場合です。すでにマージしたという印がついていれば、マージ追跡を関知するクライアントでは、マージを防げます。

すべての設定が終わって、マージ ボタンを押すだけになったとします。結果のプレビューを行う場合、マージのテスト はマージ操作を行いますが、作業コピーにいずれの変更も加えません。これで実際のマージで変更が入るファイルの一覧を表示し、また競合が発生する範囲も表示します。

マージ進行ダイアログには、マージの各状態を、リビジョン範囲とともに表示します。ここには想定していたよりも一つ多くリビジョンを表示するかもしれません。例えば、リビジョン 123 をマージするように指示した場合、進行ダイアログには、「リビジョン 122 〜 123 をマージ」 と表示されます。これを理解するには、マージは差分と密接に関連していることを思い出す必要があります。マージ処理は、リポジトリの 2 点間における差異の一覧を生成し、その差異を作業コピーに適用するというように動作します。進行ダイアログは、単純に差分の始点と終点を表示しているに過ぎません。

さて、マージが完了しました。マージ結果を見て期待通りになっているかを確認するのがいいでしょう。通常マージはかなり複雑です。ブランチがトランクからかなりずれてしまえば、しばしば競合を引き起こします。

バージョン 1.5 未満の Subversion のクライアント・サーバは、マージ情報を格納しておらず、マージしたリビジョンは、手動で追跡しなければなりません。ある変更点のテストを行い、そのリビジョンをコミットする際に、マージで取り込んだリビジョン番号を 常に コミットログに記録するべきです。あとで別のマージを適用しようとしたときに、再度変更を取り込むことがないよう、すでにマージした内容を知る必要があります。これについては Subversion Book の Best Practices for Merging をご覧ください。

サーバとすべてのクライアントが Subversion 1.5 以上の場合、マージ追跡機構がマージしたリビジョンを記録し、再度マージすることがないようにします。これにより、単純にリビジョン範囲全体を指定し、実際に新しいリビジョンのみがマージされるといったことができるようになります。

ブランチ管理は重要です。このブランチをトランクに合わせて最新の状態を維持したければ、たびたびマージを確実に行わないと、ブランチとトランクがだんだん離れていってしまうのです。もちろん上で説明したように、変更点のマージを繰り返してしまうのは避けなければなりません。

Subversion 1.5 は、マージ追跡機構を導入しました。あるツリーから別のツリーへ変更をマージすると、マージしたリビジョン番号を格納し、この情報を様々な異なる用途に利用します。

マージを行う際、クライアントはマージ追跡情報を、svn:mergeinfo に格納します。マージをコミットする際には、サーバはその情報をデータベースに格納し、マージやログ、注釈情報などのリクエストに適切に応答します。システムが適切に動作するには、サーバとリポジトリ、全クライアントを確実にアップグレードしなければなりません。以前のクライアントでは、svn:mergeinfo 属性を格納しませんし、以前のサーバでは、新しいクライアントが要求した情報を提供できません。

マージ追跡についての詳細は、Subversion の Merge tracking documentation にあります。

マージが常にすんなり完了するとは限りません。時には競合を起こしますし、複数の範囲をマージしている場合は、一般的に、次の範囲のマージを行う前に、競合を解消しておきたいでしょう。TortoiseSVN は、マージ競合コールバック ダイアログを表示して、この処理の手助けをしてくれます。

図4.39 マージ競合コールバックダイアログ

マージ中に競合が発生した場合、3 種類の選択肢があります。

この対話的コールバックが必要なければ、マージ進行ダイアログに 非対話的なマージ チェックボックスがあります。マージ時にこれをセットし、マージ結果に競合がある場合、ファイルに競合マークが付き、マージを継続します。マージがすべて完了したあとで、競合を解決しなければなりません。セットしない場合は、競合マークがファイルに付く前に、マージ中に競合解決を行う機会があります。ファイルが複数のマージ (複数のリビジョンがそのファイルに変更を与える) を受ける場合、影響を受ける行によって、続くマージが成功するという利点があります。しかしもちろん、マージ実行中には、コーヒーを入れにそこを離れるわけにはいきません。

機能ブランチの変更を、トランクにすべてマージして戻す場合、拡張コンテキストメニュー (Shift キーを押したままファイルを右クリック) にある TortoiseSVN → マージの再統合... を利用できます。

図4.40 マージ再統合ダイアログ

このダイアログは非常に簡単です。しなければならないことは、「マージオプション」 にあるように、マージオプションを設定することだけです。TortoiseSVN は、マージ追跡を利用して残りを自動的に処理します。

別々のブランチで新しい機能を開発する際、機能が完成した時の再統合指針を立てると良いと思います。別の作業がトランク (trunk) で同時に進んでいる場合、時間がたつにつれて差異は深刻になり、マージを行うのは悪夢のようになります。

機能が比較的単純で、開発に時間がかからなそうであれば、機能が完成するまで全体を分けたブランチを維持し、ブランチの変更をトランクにマージするという、単純なアプローチを採用できます。マージウィザードでは、これを単純に リビジョンの範囲をマージ で、リビジョン範囲にブランチのリビジョン期間を指定して行います。

その機能に時間がかかり、トランクに対して変更を説明する必要がある場合、ブランチの同期を維持する必要があります。これは、トランクの変更点 プラス 新機能をブランチが持つように、単純にトランクへの変更を定期的にブランチへマージするということです。同期プロセスでは リビジョンの範囲をマージ を用います。機能が完成したら、ブランチを再統合する や 異なる2つのツリーをマージ のどちらかを用いて、trunk にマージできます。

デフォルトではロックを行わず、コミットアクセスできる人が、いつでもどのファイルでも変更をコミットすることができます。他の人は自分の作業コピーを定期的に更新し、手元に行った変更をリポジトリにマージするでしょう。

ファイルのロックを取得すると、あなたしかそのファイルをコミットできなくなります。他のユーザがコミットしようとしても、あなたがロックを解放するまでできません。ロックしたファイルは、どんな方法でもリポジトリ内の変更ができません。そのため、ロック所有者を除いて削除も名前の変更もできなくなります。

しかし他のユーザは、あなたがロックしたことを知る必要はありません。定期的にロック状態をチェックしなければ、まず他のユーザはコミットが失敗して気が付くでしょう。ほとんどこのケースでしょうがあまり便利ではありません。ロックの管理を簡単にするには、新しい Subversion の属性で svn:needs-lock があります。ファイルにこの属性が (値は何でも) セットされていると、ファイルをチェックアウトや更新すると常に手元のコピーは読み取り専用になります。ファイルにロックを取得しない限りこのままです。この動作は、まずロックを取得するまでファイルの編集ができないということを警告しています。バージョン管理下で読み取り専用のファイルは、編集前にロックする必要があることを示すように、TortoiseSVN では特別なオーバーレイアイコンでマークされます。

ロックは所有者と共に作業コピーの場所に記録されます。自宅や職場など複数の作業コピーがある場合、ロックは作業コピーの中のひとつだけに記録されます。

仕事仲間の一人がロックを取得し、解放しないまま休暇を取ってしまったら、どうしたらいいでしょう? Subversion は強制的にロックする方法を用意しています。他の誰かが持っているロックを解放することを、ロックの 破壊 と呼び、他の誰かが既にロックしているファイルを強制的にロックすることを、ロックの 横取り と呼びます。当然、仕事仲間と友人でいたいなら、軽々しく行うことではありません。

ロックはリポジトリに記録されます。また、ロックトークンは手元の作業コピーに作成されます。他の誰かがロックを破壊したりして、食い違いが発生すると、手元のロックは無効になります。リポジトリは常に決定的なリファレンスです。

ロックを取得したい作業コピーのファイルを選択し、TortoiseSVN → ロックの取得... コマンドを選択してください。

図4.41 ロックダイアログ

ダイアログが現れ、コメントを入力できるようになります。そのため他の人はなぜロックしたのかが判ります。コメントはオプションで、現在のところ Svnserve ベースリポジトリでしか使用できません。他の誰かからロックを横取りする場合 (のみ) 、ロックを奪う にチェックをつけてください。その後 OK をクリックしてください。

フォルダを選択して、TortoiseSVN → ロックを取得... を使用すると、ロックするよう選択したすべてのサブフォルダ内の すべてのファイルがある状態でロックダイアログが開きます。本当に全階層をロックするのなら、これでできます。ですが、本当に仕事仲間をプロジェクトから閉め出してしまうのなら、彼らの中の評価は非常に悪くなるでしょう。慎重に使用してください...

もう必要でなくなったロックの解放を忘れないように、ロックされたファイルはコミットダイアログに表示され、デフォルトで選択されています。コミットを続けると、変更されていないとしても、選択したままのファイルのロックが解放されます。特定のファイルでロックを解放したくない場合、そのファイルのチェックを外せます (変更されていない場合)。変更したファイルのロックを保持したければ、変更をコミットする前に ロックを保持 チェックボックスを有効にしておく必要があります。

手動でロックを解放するには、ロックを解除したいファイルを作業コピーで選択し、TortoiseSVN → ロックを開放 コマンドを選択してください。追加で入力することはありません。そこで TortoiseSVN はリポジトリに接続し、ロックを解放します。フォルダに対してこのコマンドを使用し、再帰的に全ロックの解放を行えます。

図4.42 変更をチェックダイアログ

誰がロックをかけているかを確認するのに、TortoiseSVN → 変更をチェック... を使用できます。手元に保持したロックの印はすぐに現れます。他の人が保持しているロックをチェックするには (そして誰があなたのロックを破壊したり奪ったかを見るには)、リポジトリをチェック をクリックしてください。

ここのコンテキストメニューから、他の人が保持しているロックを、破壊したり横取りしたりするように、ロックを取得したり解放したりもできます。

上記のように、ロックを使用するのに最も効果的な方法は、svn:needs-lock 属性を設定することです。属性の設定については 「プロジェクト設定」 をご覧ください。この属性を持つファイルは、ロックを取得していないと、チェックアウトや更新をしたときに常に読み込み専用になります。

TortoiseSVN は、忘れないように特別なオーバーレイアイコンで表示します。

ファイルやフォルダをリポジトリに追加した際に、自動的に属性を設定するように Subversion を設定できます。詳細情報は 「属性の自動設定」 をご覧ください。

Subversion 1.2 以降で作成したリポジトリでは、リポジトリの hooks ディレクトリに 4 つフックテンプレートが追加されています。それぞれロック取得の前後、ロック解除の前後に呼ばれます。

ファイルがロックされたときに、そのファイルを表すのに email を送信するような、post-lock や post-unlock フックスクリプトをサーバにインストールするのは名案です。そういったスクリプトが適切な場所にあると、誰かがファイルをロック・ロック解放するとユーザすべてに通知されます。リポジトリフォルダの hooks/post-lock.tmpl に、サンプルフックスクリプトがあります。

フックを利用して、ロックの破壊・横取りを禁止したり、管理者に制限したりもできます。または、ロックの破壊・横取りが発生したら、ロックの所有者に email を送りたいかもしれません。

詳細は 「サーバ側フックスクリプト」 を参照してください。

まず、変更したものの make とテスト をする必要があります。それから、親フォルダで TortoiseSVN → コミット... する代わりに、TortoiseSVN → パッチを作成... を選択してください、

図4.43 パッチ作成ダイアログ

ここで完全なコミットをするときのように、パッチに含めるファイルを選択できます。これで選択したファイルに対する、リポジトリを最後に更新したときからの変更点をまとめたファイルを得ることができます。

このダイアログの列は、変更をチェック の列と同じ方法でカスタマイズできます。詳細は 「こちらの状態とあちらの状態」 をご覧ください。

違うファイルの変更点を含めた分割したパッチも生成できます。もちろん、パッチファイルを生成してから、同じ ファイルに変更を加えて別のパッチを作成すると、2 つ目のパッチには 両方 の変更点が含まれることになります。

それでは、お好みのファイル名でファイルを保存してください。パッチファイルはお好みの拡張子でかまいませんが、.patch や .diff を拡張子に使用するのが通例となっています。これでパッチファイルを送信する準備ができました。

また、ファイルに保存せずクリップボードに保存することもできます。電子メールに貼り付けて誰かにレビューしてもらう際に、そうしたくなると思います。また、1 つのマシンに 2 つ作業コピーがあり、片方からもう片方へ変更を持っていくときに、クリップボードにパッチがあるとべんりです。

作業コピーにパッチファイルを適用します。パッチを作成したフォルダと同じ階層で行う必要があります。よくわからなければ、パッチファイルの最初の行を見てください。たとえば、最初のファイルが doc/source/english/chapter1.xml に対するもので、パッチファイルの最初の行が Index: english/chapter1.xml なら、doc/source/ フォルダでパッチを適用する必要があります。適切な作業コピーを使用していても、適用するフォルダ階層が間違っていると、TortoiseSVN は適切な階層を使用するよう注意を促します。

パッチファイルを作業コピーに適用するために、少なくともリポジトリの読み込み権限が必要です。これは、他の開発者がリビジョンを変更していないかどうか、マージプログラムが参照するからです。

フォルダのコンテキストメニューから、TortoiseSVN → パッチを適用... をクリックしてください。すると「ファイルを開く」 ダイアログボックスが現れ、適用するパッチファイルを選択できます。デフォルトでは .patch ファイルか .diff ファイルのみが表示されていますが、「すべてのファイル」を選択できます。あらかじめパッチをクリップボードに保存していれば、「ファイルを開く」 ダイアログの クリップボードから開く... を使用できます。

その他には、パッチファイルが .patch や .diff といった拡張子を持つ場合、直接そのファイルを右クリックして、TortoiseSVN → パッチを適用... を選んでください。この場合、作業コピーの場所を入力することになります。

この 2 つは同じことを違う方法で行っているだけです。1 つ目は作業コピーを選択してからパッチファイルを閲覧し、2 つ目はパッチファイルを選択してから作業コピーを閲覧します。

一度パッチファイルや作業コピーの場所を選択すると、パッチファイルの変更を作業コピーにマージするように TortoiseMerge が起動します。小さなウィンドウに変更のあったファイルを表示するので、その中の項目をダブルクリックして変更の確認や、マージしたファイルの保存を行ってください。

他の開発者のパッチが適用されたので、今度は誰もがリポジトリから変更点にアクセスできるよう、コミットする必要があります。

図4.44 注釈ダイアログ

ずっと前のリビジョンに興味がなければ、注釈を見始めるリビジョンを設定できます。全リビジョンの注釈履歴を見るのなら、これを 1 に設定してください。

デフォルトでは、TortoiseBlame を使用して注釈を見ます。これは、異なるリビジョンを色分けして、見やすくしてくれます。注釈を印刷したり編集したりしたければ、注釈履歴を見るためにテキストビューアを用いる を選択してください。

改行コードや空白の変更に対する扱い方を指定できます。このオプションについては 「改行コードと空白のオプション」 で説明しています。デフォルトの振る舞いは、空白や改行コードの差異も実際の変更としますが、インデントの変更を無視してオリジナルの作者を見たい場合は、ここで適切なオプションを選択できます。

OK を押すと、TortoiseSVN は注釈ファイルを作成するため、データの取得を始めます。ファイルへの変更の量とリポジトリへのネットワーク接続に依存しますが、終了するのに数分かかることに注意してください。注釈プロセスが終了すると、結果を一時ファイルに書き出し、結果を表示します。

図4.45 TortoiseBlame

TortoiseSVN に含まれる TortoiseBlame は、注釈ファイルを読みやすくしてくれます。マウスをある行の注釈情報列の上に持っていくと、同じリビジョンの行の背景を濃くして表示します。同じ更新者が行ったけれどもリビジョンが異なる行は、薄く色を付けて表示します。ディスプレイが 256 色モードに設定されていると、きれいに色分けされない可能性があります。

行の上で 左クリック すると、同じリビジョンのすべての行に色分けされます。同じ作業者の、他のリビジョンの行は薄い色で色分けされます。この色分けは貼り付いて、色分けを失わないようにマウスを移動できます。リビジョンをもう一度クリックすると、色分けが解除されます。

注釈情報の列の上ならどこでもマウスを持ってくると、ヒントボックスの中にリビジョンのコメント (ログメッセージ) を表示します。そのリビジョンのログメッセージをコピーするには、注釈情報の列を右クリックしてでてくるコンテキストメニューを使用してください。

注釈レポートを 編集 → 検索... を使用して検索できます。これでリビジョン番号、作業者、ファイルの内容を検索できます。ログメッセージは検索できません。ログダイアログを使用して検索してください。

また、編集 → 指定した行へ移動... で指定した行番号にジャンプします。

注釈情報列の上にマウスを持っていくと、リビジョンを比較したり、履歴を検査するのに便利なコンテキストメニューが利用可能になります。この時マウスのある行のリビジョン番号を参照します。コンテキストメニュー → 前リビジョンの注釈履歴 では、同じファイルに対する前のリビジョンを上限とした注釈履歴レポートを生成します。今見ている行に対する最終更新の、直前のファイルの状態を表す注釈履歴レポートを得られます。コンテキストメニュー → 変更を表示 は、参照しているリビジョンの変更点を表示する diff ビューアを起動します。コンテキストメニュー → ログを表示は、参照しているリビジョンから始まる、リビジョンログダイアログを表示します。

もっと視覚的に変更点の新旧を見たい場合、表示 → 各行の変更時期を色分けする を選択してください。これにより、新しい行は赤、古い行は青のグラデーションで表します。デフォルトの色分けは、薄い色になっていますが、TortoiseBlame の設定で変更できます。

別のパスからマージした変更がある行でマージ追跡している場合、TortoiseBlame はマージしたところのリビジョンではなく、オリジナルファイルの最終更新のリビジョンと作者を表示します。そのような行は、リビジョンと作者をイタリックで表示します。この方法でマージした行を見ない場合は、マージ情報を含める チェックボックスのチェックを外してください。

マージされるパスを確認する場合、表示 → パスをマージ を選択してください。

TortoiseBlame の設定は、TortoiseSVN → 設定... の TortoiseBlame タブでアクセスできます。「TortoiseBlame の設定」 をご覧ください。

注釈レポートの制限に、特定のリビジョンにあるファイルしか見られず、行ごとに最終更新者しか表示できない、というものがあります。時にはどんな変更が行われたのと同じように、誰が変更を行ったかを知りたいこともあるでしょう。ここで必要となるのが、注釈レポートと差分の組み合わせです。

リビジョンログダイアログには、以下のようないくつかのオプションがあります。

各リビジョングラフのノードは、あなたが見ているツリーの、何か変更されたリポジトリのリビジョンを表しています。形や色でノードの違いを区別できます。形は固定ですが、色は TortoiseSVN → 設定 を使用して設定できます。

デフォルトでグラフには、項目の追加・コピー・削除のみ表示することにご注意ください。プロジェクト内のすべてのリビジョンを表示すると、重要なものだけでも非常に大きいグラフを生成してしまいます。本当に、変更が行われたすべてのリビジョンが必要なら、表示 メニューやツールバーに、このようにするオプションがあります。

デフォルトの表示 (グループ化無効) では、ノードを縦方向に、厳密なリビジョン順で配置するため、実行された順番の、視覚的な手がかりがあります。同じ列にあるふたつのノードの順番は明白です。ふたつのノードが隣接する列にある場合、ノードが重なる心配がないため、補正は少なくて済みます。そしてそのため、少々明白でない場合があります。そのような最適化が、複雑なグラフを妥当な大きさにしておくために必要です。この順序づけでは、古い方にあるノードの端 (つまり、グラフを古いノードを下に表示する場合は、ノードの下端) を、参照として使用することにご注意ください。ノードの形がすべて同じ大きさであるわけではないため、参照する端は重要です。

リビジョングラフは非常に複雑になることがありますので、お好みの表示にできるようにいくつもの機能があります。ツールバーの 表示 メニューから使用できます。

大きなリビジョングラフを参照するのに、外観ウィンドウを使用してください。小さなウィンドウに、図の全体を表示し、現在の表示範囲を強調しています。強調範囲をドラッグすると、表示領域が変化します。

リビジョンの日付、作者。コメントは、マウスをリビジョンボックスの上にかざしたときに出るヒントボックスに表示します。

2 つのリビジョンを選択 (Ctrl-左クリック) すると、そのリビジョン間の差分を表示するコンテキストメニューを利用できます。ブランチ作成ポイントで差分を表示できますが、通常ブランチ終了ポイント (つまり HEAD リビジョン) について表示したいことでしょう。

差分を Unified-Diff ファイル (最小の文脈で全差分を 1 ファイルにまとめたもの) で見られます。コンテキストメニュー → リビジョンを比較 を選択すると、変更したファイルの一覧が表示されます。ファイル名を ダブルクリック すると両リビジョンを取得し、視覚差分ツールで比較します。

リビジョン上で 右クリック すると、履歴を表示するのに コンテキストメニュー → ログ表示 を使用できます。

別の作業コピーにある、選択したリビジョンの変更もマージできます。フォルダ選択ダイアログにより、マージ結果を格納する作業コピーを選択できますが、確認ダイアログはなく、また動作チェックもできません。変更していない作業コピーを用い、選択したリビジョンをマージするのに失敗したら、変更を取り消すのがうまい方法です! これはあるブランチから別のブランチへ、選択したリビジョンをマージするのに便利です。

新しい情報を取得するためサーバを再チェックする場合、単純に F5 で表示を更新できます。ログキャッシュを使用する場合 (デフォルトで有効)、新しいログメッセージがあるかリポジトリをチェックし、新しいもののみを取得します。ログキャッシュがオフラインモードだった場合、オンラインモードにしようともします。

ログキャッシュを使用しており、メッセージの内容や作者を変更しようとする場合、必要なメッセージを再読込するのにログダイアログを使用するべきです。リビジョングラフはリポジトリのルートから動作しますので、ログキャッシュ全体を無効にせねばならず、キャッシュにためるのに非常に長い時間がかかります。

大きなツリーはナビゲートしにくい場合があり、一部を隠したり、小さなツリー群に分割したりしたくなると思います。ノードに出入りするノードリンクの点の上にマウスを移動すると、このための複数のポップアップボタンを目にすることになります。

付随するサブツリーを折りたたむには、-ボタンをクリックしてください。

折りたたまれたツリーを展開するには、+ボタンをクリックしてください。ツリーが折りたたまれている場合、隠されたサブツリーを表すため、表示したままとなります。

×ボタンをクリックすると、取り付けたサブツリーを分割し、独立したツリーとしてグラフに表示します。

○ボタンを押すと、分割したツリーを再度取り付けます。ツリーが遠いところで分割された際には、分割したサブツリーがあることを示すため、このボタンを表示したままとなります。

グラフの背景をクリックすると、すべて展開 や すべて連結する を提供する、メインコンテキストメニューを表示します。折りたたんだり分割したブランチがなければ、コンテキストメニューを表示しません

時には作業コピーから .svn ディレクトリを削除し、通常のフォルダに戻したい場合もあることと思います。本当に必要としているのは、新しくまっさらなディレクトリツリーを生成するのではなく、コントロールディレクトリを削除するだけの、その場でエクスポートコマンドです。

答は驚くほど単純です。フォルダを自身にエクスポートしてください! TortoiseSVN はこの特殊なケースを検出し、作業コピーをバージョン管理下から外すかどうかを聞いてきます。はい と答えると、コントロールディレクトリを削除し、まっさらなバージョン管理されていないディレクトリになります。

TortoiseSVN はいくつかのバグ追跡ツールと統合できます。このとき bugtraq: で始まる属性を使用します。以下のようにフォルダに設定しなければなりません。 (「プロジェクト設定」)

TortoiseSVN と課題追跡システムを統合するには、2 つ方法があります。ひとつは単純な文字列によるもの、もうひとつは 正規表現 によるものです。属性にはどちらの方法も使用できます。

bugtraq:message と bugtraq:logregex の両方をセットしている場合、logregex を優先します。

tsvn: 属性のいくつかは true/false 値をとります。TortoiseSVN は yes を true と同義に、no を false と同義に解釈します。

この課題追跡システムとの統合は、TortoiseSVN に限定されていません。ですから、いずれの Subversion クライアントでも使用できます。詳細は、TortoiseSVN のソースリポジトリにある、Issue Tracker Integration Specification の全体をお読みください (リポジトリのアクセスのしかたは 「TortoiseSVN は自由!」 で説明します)。

前節では、ログメッセージへ課題情報の追加について扱いました。しかし、課題追跡システムから情報を取得する必要がある場合、どのようにしたらよいのでしょう? コミットダイアログは、課題追跡システムと会話ができるような、外部プログラムを統合する COM インターフェースを備えています。通常、今回のコミットで取り組む課題を取り上げられるように、自分に割り当てられた未解決の課題を取得するよう、課題追跡システムに問い合わせを行うのでしょう。

Any such interface is of course highly specific to your issue tracker system, so we cannot provide this part, and describing how to create such a program is beyond the scope of this manual. The interface definition and sample plugins in C# and C++/ATL can be obtained from the contrib folder in the TortoiseSVN repository. (「TortoiseSVN は自由!」 explains how to access the repository). A summary of the API is also given in 6章IBugtraqProvider インターフェース Another (working) example plugin in C# is Gurtle which implements the required COM interface to interact with the Google Code issue tracker.

説明のために、あなたのシステム管理者が、あなたがインストールした課題管理システムプラグインを提供し、TortoiseSVN の設定ダイアログでそのプラグインを使用する作業コピーをセットアップしたとしましょう。プラグインに割り当てられた作業コピーからコミットダイアログを開くと、ダイアログの上部に新しいボタンが現れるはずです。

図4.50 課題追跡システムクエリダイアログの例

この例では、複数の未解決課題を選択できます。その後、プラグインがログメッセージに追加する、特定のフォーマットのテキストを生成できます。