Subversion はリポジトリの作成、調査、修正、修復に便利なユー ティリティーをいくつも提供しています。それぞれについてもっと詳し く見てみましょう。その後 Berkeley DB のディストリビューションに含 まれるユーティリティーのいくつかを簡単にためしてみます。 Berkeley DB は Subversion 自身のツールとしては提供していないリポ ジトリデータベースバックエンドに特化した機能を提供しています。

$ svnlook help
general usage: svnlook SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ...]
Note: any subcommand which takes the '--revision' and '--transaction'
      options will, if invoked without one of those options, act on
      the repository's youngest revision.
Type "svnlook help <subcommand>" for help on a specific subcommand.
…

$ svnlook info /path/to/repos
$ svnlook info /path/to/repos --revision 19

$ svnlook youngest /path/to/repos
19

$ svnlook info /path/to/repos
sally
2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002)
27
Added the usual
Greek tree.

$ svnlook tree /path/to/repos --show-ids
/ <0.0.1>
 A/ <2.0.1>
  B/ <4.0.1>
   lambda <5.0.1>
   E/ <6.0.1>
    alpha <7.0.1>
    beta <8.0.1>
   F/ <9.0.1>
  mu <3.0.1>
  C/ <a.0.1>
  D/ <b.0.1>
   gamma <c.0.1>
   G/ <d.0.1>
    pi <e.0.1>
    rho <f.0.1>
    tau <g.0.1>
   H/ <h.0.1>
    chi <i.0.1>
    omega <k.0.1>
    psi <j.0.1>
 iota <1.0.1>

$ svnadmin help
general usage: svnadmin SUBCOMMAND REPOS_PATH  [ARGS & OPTIONS ...]
Type "svnadmin help <subcommand>" for help on a specific subcommand.

Available subcommands:
   create
   deltify
   dump
   help (?, h)
…

$ svndumpfilter help
general usage: svndumpfilter SUBCOMMAND [ARGS & OPTIONS ...]
Type "svndumpfilter help <subcommand>" for help on a specific subcommand.

Available subcommands:
   exclude
   include
   help (?, h)

/
   calc/
      trunk/
      branches/
      tags/
   calendar/
      trunk/
      branches/
      tags/
   spreadsheet/
      trunk/
      branches/
      tags/

$ svnadmin dump /path/to/repos > repos-dumpfile
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
* Dumped revision 3.
…
$

$ cat repos-dumpfile | svndumpfilter include calc > calc-dumpfile
…
$ cat repos-dumpfile | svndumpfilter include calendar > cal-dumpfile
…
$ cat repos-dumpfile | svndumpfilter include spreadsheet > ss-dumpfile
…
$

Node-path: calc
Node-action: add
Node-kind: dir
Content-length: 0

$ svnadmin create calc; svnadmin load calc < calc-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : button.c ... done.
…
$ svnadmin create calendar; svnadmin load calendar < cal-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : cal.c ... done.
…
$ svnadmin create spreadsheet; svnadmin load spreadsheet < ss-dumpfile
<<< Started new transaction, based on original revision 1
     * adding path : Makefile ... done.
     * adding path : ss.c ... done.
…
$

…
Node-path: spreadsheet/Makefile
…

Subversionリポジトリは一般的にいったん設定してしまえばほとんど 注意を払う必要はありません。しかし、管理者による、いくつかの 補助が必要かも知れません。svnadmin ユーティリティー には以下のような作業を助けるための機能があります。それは

svnadminのサブコマンドで一番よく使われるのは 多分 setlogです。トランザクションがリポジトリに コミットし、リビジョンを表示したとき、新しいリビジョンに関連した ログメッセージは、そのリビジョン自体のバージョン化されない属性として 格納されます。言い換えると、リポジトリはその属性の最後の値だけを 記憶していて、以前のものは捨ててしまいます。

ときどきユーザはログメッセージに間違いを見つけます(スペルミスや 間違った情報など)。もしリポジトリが( pre-revprop-change と post-revprop-change フックを使って。 フックスクリプト項参照) コミット完了後このログメッセージの変更を受け付けるとすると ユーザは、svn プログラムの propsetコマンドを使ってログメッセージを ネットワーク越しに「修正」 することができます。 (章 9. Subversion リファレンス参照) しかし、情報が永久に失われてしまうことを防ぐため、Subversion リポジトリはデフォルトではそれをさせません。デフォルトは、 バージョン化されない属性は、管理者のみが変更することが できます。

もしログメッセージを管理者が変更する必要がある場合、 svnadmin setlogを使います。このコマンドは リポジトリの指定したリビジョンのログメッセージ(svn:log 属性 )を、用意したファイルから新しい値を読み出し形で変更します

$ echo "Here is the new, correct log message" > newlog.txt
$ svnadmin setlog myrepos newlog.txt -r 388

svnadmin setlog コマンドだけでは、リモートクライアント としてバージョン化されていない属性を修正する場合と同じ制約を 受けます—つまりpre-とpost-revprop-change フックはやはり実行され、この仕組みで変更される修正点は反映されて しまいます。しかし管理者はこのような保護機能をsvnadmin setlog コマンドに--bypass-hooksを指定することで回避できます。

別のよくある svnadmin の使い方は終了していない —多分死んでしまった—Subversionトランザクションに関する リポジトリへの問い合わせです。コミットが失敗したとき、普通 トランザクションはきれいに消去されます。つまりトランザクション はリポジトリから削除され、そのトランザクションに(だけに)関連した データも同様に削除されます。 しかし、しばしばトランザクションの掃除が起こらずに失敗することが あります。これにはいくつかの理由が考えられます: 多分クライアントの 操作がユーザによって乱暴に終了されたか、ネットワークの異常などが 処理の途中で起こった場合です。理由にかかわらず、死んだままの トランザクションが残ることはありえます。ディスクをわずかに食うことを のぞけば、このようなトランザクションは全く無害です。それでも 潔癖な管理者はこのようなトランザクションを削除したいと思うかも 知れません。

svnadminのlstxns コマンド を使って、その時点での未完了のトランザクションの名前の一覧表示 することができます。

$ svnadmin lstxns myrepos
19
3a1
a45
$

出力結果のそれぞれの項目はsvnlook (とその--transaction オプション)で 使うことができ、誰がトランザクションを作り、それは いつで、どのような変更がトランザクションに起きたか、を 知ることができます。 —言い換えると、そのトランザクションは削除対象として 安全な候補なのかどうか、ということをです。もしそうなら、 トランザクションの名前をsvnadmin rmtxns に渡すことができ、そのトランザクションはきれいに削除 されます。rmtxns サブコマンドは、 lstxnsの出力をそのまま入力として とることもできます!

$ svnadmin rmtxns myrepos `svnadmin lstxns myrepos`
$

このような二つのサブコマンドを使う場合、リポジトリを一時的に クライアントからアクセスできなくする必要があります。 これで誰もあなたがクリーンアップを始める前に正しいトランザクション を開始できなくなります。以下は、リポジトリ内の未解決のトランザクション のそれぞれについての情報をすばやく生成するためのちょっとした スクリプトです:

#!/bin/sh

### Generate informational output for all outstanding transactions in
### a Subversion repository.

REPOS="${1}"
if [ "x$REPOS" = x ] ; then
  echo "usage: $0 REPOS_PATH"
  exit
fi

for TXN in `svnadmin lstxns ${REPOS}`; do 
  echo "---[ Transaction ${TXN} ]-------------------------------------------"
  svnlook info "${REPOS}" --transaction "${TXN}"
done

このスクリプトを /path/to/txn-info.sh /path/to/reposのように して実行できます。出力は基本的にはsvnlook info 出力のいろいろな断片をつないだようなものになります。 (svnlook項参照), 以下のような 感じです:

$ txn-info.sh myrepos
---[ Transaction 19 ]-------------------------------------------
sally
2001-09-04 11:57:19 -0500 (Tue, 04 Sep 2001)
0
---[ Transaction 3a1 ]-------------------------------------------
harry
2001-09-10 16:50:30 -0500 (Mon, 10 Sep 2001)
39
Trying to commit over a faulty network.
---[ Transaction a45 ]-------------------------------------------
sally
2001-09-12 11:09:28 -0500 (Wed, 12 Sep 2001)
0
$

長く放置されているトランザクションは普通は何かに失敗したか、コミットを 中断されたかのどちらかです。トランザクションの日付スタンプは 役に立つ情報を与えてくれます — たとえば 9 ヵ月も前に始まった 操作がいまだに有効である可能性など、いったいどの程度あるのでしょうか?

簡単に言って、トランザクションのクリーンアップの決定は、無分別に やる必要はありません。いろいろな情報源—Apacheのエラーログや アクセスログ、成功したSubversionのコミットログ、などなど—が どうしたら良いかを決める上で役に立ちます。最後に、管理者はしばしば 死んだトランザクションの所有者と思われる人と、(メールなどで)その 死にかかったトランザクションの状態を確認することができます。

ここ数年で記憶装置のコストは非常に低くなってきた一方で、ディスクの利用方法 は、大量のデータをバージョン管理するために、システム管理者にとっては、やはり 依然として考慮すべきことです。動作中のリポジトリによって消費される追加の 領域はオフラインでバックアップすることが必要な領域でもあり、バックアップ のスケジュール管理を考えると、何倍かになるでしょう。Berkeley DB リポジ トリを使う場合には、データ保管の仕組みは複雑なデータベースシステムである ので、データのどの部分をオンラインのままに残し、どの部分にバックアップが 必要で、どの部分を安全に削除できるか、ということについて理解しておくことには 意味があります。 この節は Berkeley DB だけに関係しています。FSFS リポジトリには削除したり、 調整が必要な特殊な追加データはありません。

最近まで、Subversion リポジトリに関して最も多くディスクを消費する部分は Berkeley DB が実際にデータベースファイルを修正する前に前もっと書き込むための ログファイルの領域でした。これらのファイルはデータベースのある状態から 別の状態への変化の経緯にそったすべての操作を記録します— データベース ファイルはある特定の時刻にその状態を反映される一方でログファイルはその前後 の状態のすべての本稿を含んでいます。そのようなわけでログファイルは非常に 早いスピードでサイズを増やします。

ありがたいことに、Berkeley DB のリリース 4.2 からデータベース環境は 特に外部操作することなしに未使用のログファイルを削除する能力を持つ ようになりました。Berkeley DB バージョン 4.2 かそれ以降でコンパイルされた svnadminはこの自動的なログファイルの削除が設定 されています。この機能を有効にしたくない場合には単に svnadmin createコマンドで--bdb-log-keep を渡してください。これを忘れたり、後で変更したい場合には、単に リポジトリのdbディレクトリ中にあるDB_CONFIG を編集して、set_flags DB_LOG_AUTOREMOVEディレクティブをコメントアウトしてから この変更を強制的に有効にするためにそのリポジトリに対してsvnadmin recover を実行してください。データベースの設定についての詳細は Berkeley DB の設定項を参照してください。

このような自動ログファイル削除の仕組みを利用しなければ、 リポジトリを利用するにつれてログファイルは蓄積されていきます。 それてこれは実際にデータベースシステムであれば当然付いている機能です— ログファイル以外に何も残っていないような状況でデータベース全体を再構成する ことができるようになっていなくてはならず、そのようなログファイルは データベースの壊滅的な破壊からの復旧で利用できなければならないからです。 しかし普通は Berkeley DB で既に利用されていないログファイルをアーカイブし、 その後ディスクから削除することで領域を広げようとするでしょう。利用していない ログファイルの一覧を見るにはsvnadmin list-unused-dblogsコマンドを使ってください:

$ svnadmin list-unused-dblogs /path/to/repos
/path/to/repos/log.0000000031
/path/to/repos/log.0000000032
/path/to/repos/log.0000000033

$ svnadmin list-unused-dblogs /path/to/repos | xargs rm
## disk space reclaimed!

リポジトリのデータサイズをできるだけ小さくするために Subversion は リポジトリに対して差分化(あるいは「 差分記憶」) の処理をします。差分化は別のデータの部分に対する 差分の集まりをひとつのデータの塊として表現するものです。二つのデータ が非常に似ていればこの差分化は差分化されたデータの記憶領域を節約します —もとのデータサイズと同じだけの領域を確保するのにくらべて小さく なります。いわば、「以下の変更点をのぞけば、他の点についてはここに あるデータのままですよ」という表現に必要なだけの領域で済みます。 具体的に言うと、ファイルの新しいバージョンがリポジトリにコミットされる たび、Subversion は前のバージョン(実際には前のバージョンのいくつか)を この新しいバージョンに対する差分として表現します。その結果、大きくなり がちなリポジトリデータ—つまりバージョン化されたファイルの内容 —の大部分を、もとの「完全なテキスト」として 保存するよりはずっと小さなサイズで格納することができます。

Berkeley DB項で触れたように、Berkeley DB リポジトリは正しく閉じられなかった場合には中間的な状態に固まってしまう ことがあります。こうなった場合管理者はデータベースを以前の一貫した状態 にまで戻してやる必要があります。

リポジトリ中のデータを保護するため Berkeley DB はロックのしくみ を利用しています。このしくみはデータベースの特定のが同時に複数のデータベー スアクセスによって修正されないことを保証するためのもので、それぞれのプ ロセスから見たときには、読み込み時にはデータは正しい状態にあるように見 えます。データベース中のどこかを変更する必要ある場合にはまず対象となる データがロックされていないかどうかを確認します。もしロックされていなけ ればそのプロセスはデータをロックし、必要な修正を加え、そのデータに対す るロックを外します。他のプロセスはデータベースの内部に引き続きアクセス できるようになる前にロックファイルが削除されるまで待たされます。

Subversionリポジトリを使う上で、致命的なエラー(ディスクがいっぱいに なったり、メモリがなくなったり)や、割り込みによって、データベースに かけたロックを削除する機会をなくしてしまうことがあります。その結果 バックエンドのデータベースは「固まって」しまいます。 こうなったときには、リポジトリへのどのようなアクセスも永久に待たされる ことになってしまいます。(というのは、すべての新しいアクセスはロック が解除されるのを待ちますが、それは決してやってこないからです)

まず、そういうことがリポジトリに起こっても、悲鳴をあげないで ください。Berkeley DBのファイルシステムはデータベーストランザクション とチェックポイント、それに事前ジャーナル書き込みの仕組みをうまく 利用していて、本当に破滅的な出来事以外は ^[17] データベース環境を永久に葬り去ることはできないことを保証します。 十分神経質なリポジトリ管理者は何んらかの方法でリポジトリデータの オフラインバックアップをとっているかも知れませんが、バックアップテープを リストアしてくれとシステム管理者を呼ぶのはまだです。

次に、以下の手順を使って、リポジトリの「復旧」 を試してみてください:

この方法はほとんどのリポジトリロックを解消します。このコマンドは 単に rootになるのではなく、データベース を所有し、管理しているユーザで実行することに注意してください。 復旧作業は、傷を負ったいろいろなデータベースファイル からの再作成の作業も含みます。(たとえば共有メモリ領域などです) root での復旧は、root が 所有しているファイルを作成することで、これはリポジトリへの 接続状況が復旧した後でも通常のユーザはこれに対してアクセスする ことができないことを意味します。

もしいま述べた作業が、何かの理由でうまくリポジトリを正常に 戻せない場合、二つのことをすべきです。まず、壊れたリポジトリを どけて、最後のバックアップをリストアします。それからSubversion のユーザリストにメールします。(これは、 <users@subversion.tigris.org>です)このとき問題点を詳しく 説明してください。データの一貫性は、Subversion開発者にとって 非常に高いプライオリティです。

Subversionファイルシステムはさまざまなデータベーステーブルに分散された データを持ちますが、これは一般的にはSubversion開発者だけが知っている (て、興味のある)ことです。しかし、すべての、あるいは一部のデータを 一つの、持ち運びに便利な単純なファイル形式にまとめたいことがあります。 Subversion はそのような仕組みをsvnadmin サブコマンド の組によって実装しています: dump と loadです。

Subversionリポジトリをダンプしたりロードしたりする一番よくある理由は Subversion自身の変更にあります。Subversion が完成に近づくにつれ、 バックエンドデータベースのスキーマ変更によっては リポジトリの前のバージョンとの互換性がなくなってしまいます。 ダンプとロードが必要になる他の理由としては、Berkeley DB を他の OS や CPU アーキテクチャに以降する場合、あるいはBerkeley DB と FSFS バックエ ンド間を切り替えて使う場合です。このために推奨されている作業ステップは比較 的簡単です:

svnadmin dump は、リポジトリリビジョンのある 範囲を出力しますが、それはSubversionのカスタムファイルシステム ダンプ形式になっているものです。ダンプ形式は標準出力に表示され、 進行状況などのメッセージは標準エラー出力に表示されます。これで 出力をファイルにリダイレクトすることができ、その一方でステータス の出力については端末ウィンドウ上で見ることができます。たとえば:

$ svnlook youngest myrepos
26
$ svnadmin dump myrepos > dumpfile
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.
…
* Dumped revision 25.
* Dumped revision 26.

処理の最後で、指定した範囲のリポジトリリビジョンのデータすべて が保存された一つのファイル(前の例では、dumpfile) を手に入れることができます。 svnadmin dumpは他の「読み出し」プロセス(たとえばsvn checkout など)がやるのと同じような 方法でリポジトリからリビジョンツリーを読み出すことに 注意してください。そのため、このコマンドはいつでも安全に実行できます。

組になったもう一方のサブコマンドであるsvnadmin loadは、標準入力を、Subversionリポジトリのダンプファイルと して解析し、ダンプされたリビジョンを目的のリポジトリに再現します。 それはまた経過情報などを返しますが、こちらは標準出力に 表示します:

$ svnadmin load newrepos < dumpfile
<<< Started new txn, based on original revision 1
     * adding path : A ... done.
     * adding path : A/B ... done.
     …
------- Committed new rev 1 (loaded from original rev 1) >>>

<<< Started new txn, based on original revision 2
     * editing path : A/mu ... done.
     * editing path : A/D/G/rho ... done.

------- Committed new rev 2 (loaded from original rev 2) >>>

…

<<< Started new txn, based on original revision 25
     * editing path : A/D/gamma ... done.

------- Committed new rev 25 (loaded from original rev 25) >>>

<<< Started new txn, based on original revision 26
     * adding path : A/Z/zeta ... done.
     * editing path : A/mu ... done.

------- Committed new rev 26 (loaded from original rev 26) >>>

load の結果、新しいリビジョンがリポジトリに追加されます—これは 通常の Subversion クライアントからリポジトリに対してコミットをする のと同じ効果があります。またやはりコミットと同様に load 処理中に おきるそれぞれのコミットの前後で実行するフックスクリプトを使うことも できます。 svnadmin load に --use-pre-commit-hook と --use-post-commit-hook オプションを渡すことでロードされるリビジョンごとに Subversion に 対してそれぞれ pre-commit と post-commitのフックスクリプトを実行する ように指示できます。これで例えば、通常のコミット時と同様の妥当性チェック のようなステップをロードされるリビジョンごとに保障するような使い方が できます。もちろんこのようなオプションの利用には注意が必要です— post-commit フックスクリプトで新しいコミットごとにメーリングリストに対して email を送信するようになっていた場合、リビジョンがロードされるたびに リストに数え切れないくらいの email を流したいとは思わないでしょう ! フックスクリプトについては フックスクリプト項 により詳しい情報があります。

svnadmin は標準入力と標準出力をリポジトリのダンプ とロード処理に使うので、気の利いた人は、以下のようなやり方を試す こともできます(おそらく、パイプの両側のsvnadmin は、異なるバージョンであるかも知れません):

$ svnadmin create newrepos
$ svnadmin dump myrepos | svnadmin load newrepos

デフォルトではダンプファイルは非常に大きくなります—リポジトリ 自体よりもずっと大きくなるでしょう。理由はすべてのファイルのすべての バージョンは、ダンプファイル中では完全なテキストとして表現される からです。これはダンプデータをパイプ経由で他のプロセス(圧縮プログラム や、フィルタープログラム、あるいはロードプロセスのようなもの)に送る場合には もっとも早く単純な方法です。しかし長期保存用にダンプファイルを作成する のであれば --deltasスイッチを使ってディスク領域を節約 したほうが良いでしょう。このオプションを使うと引き続くリビジョン間の ファイルは圧縮された形のバイナリ差分として出力されます—これはちょ うどリポジトリ中に保存されたリビジョンファイルと同じような形になります。 このオプションを使うと処理は遅くなりますが結果のダンプファイルは 元のリポジトリにかなり近いサイズにまでなります。

前に注意したようにsvnadmin dump はリビジョンの範囲を出力します。 --revision オプションを使えば、一つの リビジョンのダンプや、リビジョン範囲のダンプができます。 このオプションを省略すれば、すべての存在するリポジトリ リビジョンがダンプされます。

$ svnadmin dump myrepos --revision 23 > rev-23.dumpfile
$ svnadmin dump myrepos --revision 100:200 > revs-100-200.dumpfile

Subversionはそれぞれの新しいリビジョンをダンプするのでその出力には 後で実行されるローダが前のリビジョンを元にしてそのリビジョンを再 作成するのに必要な十分な情報があります。 言い換えると、ダンプファイル中でどのようなリビジョンが指定されても リビジョン中で変更のあったアイテムのみがダンプに現れるということ です。この規則の唯一の例外は、現在のsvnadmin dump がダンプする最初のリビジョンです。

デフォルトでは、Subversionは前のリビジョンに対する単なる差分として 最初のダンプリビジョンを表現することはありません。この理由の一つは 、ダンプファイルには直前のリビジョンがないからです! 二番目にSubversion はダンプデータがロードされるリポジトリの状態について何も知らない からです。(もしロードが起こるとすれば、ですが。) svnadmin dump の個別の実行の出力が自己充足して いるのを保証するため、最初のダンプリビジョンはデフォルトでは すべてのディレクトリ、ファイル、リポジトリにあるそのリビジョンの属性 の完全な表現になっています。

しかし、このデフォルトの振る舞いを変えることもできます。リポジトリを ダンプするときに--incremental オプションを追加すると svnadmin は最初のダンプリビジョンとリポジトリ中の 直前リビジョンとの差分をとろうとします。残りのすべてのダンプ されるリビジョンにも同じ方法で扱います。 それからダンプ範囲にある残りのリビジョンが出力するのと同じように 最初のリビジョンを—リビジョン中に起こる変更だけを 考慮して出力します。 この利点は大きな一つのダンプファイルのかわりに、ロードに成功するような 小さないくつものダンプファイルを作ることができることです。 こんな感じです :

$ svnadmin dump myrepos --revision 0:1000 > dumpfile1
$ svnadmin dump myrepos --revision 1001:2000 --incremental > dumpfile2
$ svnadmin dump myrepos --revision 2001:3000 --incremental > dumpfile3

これらのダンプファイルは以下のようなコマンドの流れで 新しいリポジトリ中にロードされます:

$ svnadmin load newrepos < dumpfile1
$ svnadmin load newrepos < dumpfile2
$ svnadmin load newrepos < dumpfile3

--incremental オプションを使った別の かっこいい方法は、既に存在しているダンプファイルに 新しいダンプリビジョン範囲を追加することです。たとえば post-commit フックがあり、それは単に フックをトリガーするような一つのリビジョンのリポジトリ ダンプを追加するものです。あるいは最後にスクリプトを実行した時点より 後にリポジトリに追加されたすべてのリビジョンに対してのダンプファイルを追加する ようなスクリプトを実行するかも知れません。このように利用することで svnadminの dump と load コマンドは 価値のある手段となりますが、これによって、リポジトリの変更を 時間をかけてバックアップして、システムクラッシュや、他の壊滅的な出来事に そなえるというわけです。

ダンプ形式はまたさまざまな異なるリポジトリの 内容を単一のリポジトリにマージするために利用することもできます。 svnadmin loadの --parent-dirオプションを使って ロードプロセス用の新たな仮想ルートディレクトリを指定することが できます。これは、もしcalc-dumpfile, cal-dumpfile, そして ss-dumpfileという三つのリポジトリ のダンプファイルがある場合、最初にそれらすべてを保持するような 新しいリポジトリを作ることができることを意味します:

$ svnadmin create /path/to/projects
$

それから三つの以前のリポジトリのそれぞれの内容を含んだ 新しいディレクトリをリポジトリ中に作ります:

$ svn mkdir -m "Initial project roots" ¥
      file:///path/to/projects/calc ¥
      file:///path/to/projects/calendar ¥
      file:///path/to/projects/spreadsheet
Committed revision 1.
$ 

最後に個々のダンプファイルを新しいリポジトリのそれぞれの 場所にロードします:

$ svnadmin load /path/to/projects --parent-dir calc < calc-dumpfile
…
$ svnadmin load /path/to/projects --parent-dir calendar < cal-dumpfile
…
$ svnadmin load /path/to/projects --parent-dir spreadsheet < ss-dumpfile
…
$

Subversion リポジトリダンプ形式の利用方法について最後にもう一つだけ 触れます— 異なる保存の仕組みやバージョン管理システムから データを変換する方法です。これができる理由はダンプファイル形式は ほとんどの部分が可読であるためです。 ^[18] このファイル形式を 使うと、比較的簡単に一般的な変更点のセットを表現することができます— それぞれの変更は新しいリビジョンとして扱われます。 事実、cvs2svnユーティリティー(CVS から Subversion へのリポジトリ変換項参照)は、CVS リポジトリの内容を表現するのに ダンプ形式を使うので、その内容を Subversion リポジトリに取り込むことができます。

現代的なコンピュータが生まれてから技術的には非常に発展してきたものの、 残念なことに、一つのことだけは間違いなく真実です—ときどき、ものごとは まったく台無しになってしまう、ということです。停電、ネットワーク切断、 RAMの破壊、ハードディスクのクラッシュは、魔物以外の何者でもありません。 運命は最も優れた管理者にさえ降りかかるのです。それで、とても重要な トピックに行き着きます—どうやってリポジトリのバックアップを とるか、です。

一般的に、Subversionのリポジトリ管理者にとって、二つのバックアップ方法が あります—差分バックアップと、フルバックアップです。この章の前の節で どうやってsvnadmin dump --incremental を使って差分 バックアップをとるかを議論しました (リポジトリの移行項参照)。本質的にこのアイディアは最後に バックアップをとってから起きたリポジトリの変更部分だけをバックアップ する方法です。

リポジトリのフルバックアップは文字通りリポジトリディレクトリ全体の 複製を作ることです(これはBerkeleyデータベース環境も含まれます) さて、一時的にリポジトリに対するすべてのアクセスを禁止しなければ、 単純な再帰的なディレクトリコピーの実行は、不完全なバックアップを作って しまう危険を持っています。というのは誰かが並行してデータベースに書き込んで いるかも知れないからです。

Berkeley DB の場合、Sleepycat のドキュメントは正しいバックアップコピーを 保証するようにデータベースファイルをコピーする場合の順序が書いて あります。同様の順序が FSFS データにもあります。しかしこのよう なプログラムを自分で書く必要はありません。Subversion 開発チー ムがすでにしているからです。 hot-backup.py スクリプトはSubversionのソース パッケージのtools/backup/ ディレクトリにあります。 リポジトリパスとバックアップ位置を指定すると、hot-backup.py —それは単にsvnadmin hotcopyコマンドのより賢い ラッパープログラムでしかありませんが— は、動作中のリポジトリをハックアップするのに必要なステップを実行します —あなたにリポジトリアクセスを禁止することなしに、です— ついでに、動作中のリポジトリから、死んでいる Berkeley ログファイルを きれいに削除します。

差分バックアップがあるとしても、規則的にこのプログラムを実行したく なるかも知れません。たとえばhot-backup.py を プログラムスケジューラに追加しようと考えるかも知れません (Unix であればcrond のようなもの)。 あるいは、細かい粒度のバックアップが好きなら、hot-backup.py を呼ぶような、post-commitフックスクリプトを書くこともできます。 (フックスクリプト項参照)。これは新しいリビジョンが 作られるたひにリポジトリの新しいバックアップができる方式です。 単に、以下を動作中のリポジトリディレクトリにある hooks/post-commit に追加してください:

(cd /path/to/hook/scripts; ./hot-backup.py ${REPOS} /path/to/backups &)

結果のバックアップは、完全に機能するSubversionリポジトリで、現行の リポジトリが何かひどいことになったときには、置き換えて使うことが できるものです。

両方のバックアップ方法にはそれぞれ利点があります。一番簡単なのは フルバックアップで、それは常に現行リポジトリの完全なコピーです。 繰り返しになりますが、何かまずいことが動作中のリポジトリに起きた 時には、単純な再帰的なディレクトリコピーでこのバックアップを 復元することができます。残念なことに、もしリポジトリの複数のバックアップ を管理している場合、このようなフルコピーは、実行中のリポジトリと 同じくらい、それぞれがディスクを食うということです。

リポジトリダンプ形式を使った差分バックアップはデータベーススキーマ が引き続くSubversion自身のバージョン間で変更されるときには非常に 役に立ちます。リポジトリの完全なダンプとロードは一般的に リポジトリを新しいスキーマにアップグレードすることが必要です。 そのような作業の半分(つまり、ダンプの部分)については既に 済んでいるのでとても便利です。不幸にも、差分バックアップの 作成—そしてそのリストア—は長い時間がかかりますが、 それは、それぞれのコミットがダンプファイル、またはリポジトリの 中で、実際に再実行されるからです。

どちらのバックアップの場合も、リポジトリ管理者は どのようにしてバージョン化されない属性への変更がバックアップに影響を 与えるかに注意する必要があります。このような変更は新しいリビジョンを それ自体で作り出すわけではないので、post-commitフックを呼び出すきっかけ にはならず、pre-revprop-chage や post-revprop-change フックのきっかけ にすらならないでしょう。 ^[19] そして、時間の順序に沿わないでリビジョン属性を変更することができる —いつでも、どのリビジョン属性を変更することができます— ので、最後のいくつかのリビジョンの差分バックアップはそれ以前の バックアップの一部として行われたリビジョン属性の修正は取り入れる ことができません。

一般的に言って、本当に人間離れした潔癖さを持った人だけが完全なリポジトリ のバックアップを必要とするのでしょう。つまり、コミットが起こるたびに バックアップをとるわけです。しかし、そのリポジトリが相対的に細かい 粒度(コミットごとのメールなど)と共に、何か別の冗長性の仕組みを持って いるのであれば、データベースのホットバックアップはリポジトリ管理者が システム全体の日次バックアップの一環として導入したいと考えるものかも知れません。 ほとんどのリポジトリでは、コミット メール をアーカイブするだけで復旧元 データとしての十分な冗長性を持っています。少なくとも最近のいくつかのコミット についてはそうです。しかしデータはとにかくあなたのものです— 必要なだけ保護するのに越したことはありません。

しばしば、リポジトリのバックアップに対する最良の方法は、分散 させることです。フルバックアップと差分バックアップに、コミット メールのアーカイブを追加することができます。たとえばSubversion 開発者は、Subversionソースコードリポジトリを、新しいリビジョン が作られるたびにバックアップします。そして、すべてのコミットと 属性変更の通知メールをアーカイブしてとっておきます。同様の方法を とってください。ただし、必要な範囲で、便利さと安全性の微妙なバラ ンスをとってください。そして、このようなことを全部やっても、運命 の鉄拳からハードウェアを守ることはできないことに注意してください。 ^[20] バックアップは確かにそのような試練の時からあなたを救うはずです。