Subversionのリポジトリ層を参照するとき、一般的に、二つのライブラリに ついて語っています—リポジトリライブラリとファイルシステムライブラリ です。これらのライブラリはバージョン管理されたデータのさまざまなリビジョン のための格納と報告の仕組みを提供しています。この層はリポジトリアクセス層 を経由してクライアント層とつながっていて、Subversion利用者から見ると、 「通信の相手先」にあるものに見えます。

Subversionのファイルシステムはlibsvn_fs APIによってアクセスされ、 オペレーティングシステムにインストールされているカーネルレベルの 意味でのファイルシステム(Linuxのext2 や、NTFSのような)ではなく、 仮想的なファイルシステムのことです。「ファイル」と 「ディレクトリ」を (自分の好きなシェルを使って操作することができるような)現実の ファイルとディレクトリとして保存するのではなく、バックエンドの 抽象的な保存の仕組みとして二つのうちのどちらかが利用可能です — Berkeley DB データベース環境か、フラットファイルによる 表現です。(この二つのバックエンドについてより深く知りたい場合は リポジトリの保存形式項を見てください)。 しかし、Subversionの今後のリリースの中で開発コミュニティによって 興味を引いている、別のバックエンドデータベースシステムの利用 可能性があります。たとえば、オープンデータベースコネクティビティー (ODBC)などです。

libsvn_fs が提供するファイルシステムAPIは他のファイルシステムAPI でも期待できるような機能を持っています: ファイルやディレクトリの 作成や削除ができて、コピーや、移動ができ、ファイルの内容を 修正することができて、などなどです。あまり一般的ではないような 機能もあります。たとえば、ファイルやディレクトリに付随した メタデータ(「属性」)の追加、変更、削除、などです。さらに Subversionファイルシステムはバージョン化可能なファイルシステムで、 これは、ディレクトリツリーに変更を加えると、Subversionはその変更 以前に、そのツリーがどのように見えるかを憶えておくということを 意味します。そして、さらにその前の変更前、さらにその前、などです。 このようにして、ファイルシステムに何かを最初に追加したところまでの すべてのバージョンに戻ることができます。

ツリーに加えたすべての変更はSubversionのトランザクションの中で実行 されます。以下は、ファイルシステムを修正するための単純で一般的な 手続きです:

トランザクションをコミットすると、ファイルシステムの変更は歴史上の 出来事として永久に記録されます。このようなそれぞれのサイクルは ツリーに新しいリビジョンを作り、それぞれのリビジョンは「あることが どのようであったか」という純粋なスナップショットとしていつでもアクセス できるようになります。

ファイルシステムインターフェースによって用意される機能のほとんどは ファイルシステムパスに対して起こる操作として提供されます。 つまり、ファイルシステムの外部からは、ファイルやディレクトリの個別の リビジョンを記述し、アクセスする、主要な仕組みは、/foo/bar のようなパス文字列を使うことを通じて提供され、それはちょうど、あなたが なじみのシェルプログラムを通じてファイルやディレクトリにアクセスする ような感じになります。適切なパス名を正しいAPI関数に渡すことによって、 新しいファイルやディレクトリを追加することができます。同じ仕組みを使って そのファイルなどに関した情報を問い合わせることができます。

ほとんどのファイルシステムとは違い、パスだけを指定するのは、Subversion のファイルやディレトクリを特定するのに十分な情報ではありません。 ディレクトリツリーを二次元のシステムと考えてください。ここで、あるノードの 兄弟は、左から右に移動することを表現していて、サブディレトクリに降りていく のは、下向きの移動であると考えてください。図 8.1. 「二次元の中のファイルとディレクトリ」 は典型的なツリーの 表現を示しています。

図 8.1. 二次元の中のファイルとディレクトリ

もちろんSubversionのファイルシステムは隠れた第三の次元を持っていますが、 それはほとんどのファイルシステムが持っていないものです—それは時間の次元です! ^[41] ファイルシステムインターフェースで、path 引数を 持つほとんどすべての関数はまたroot 引数も指定し なくてはなりません。このsvn_fs_root_t 引数は、 リビジョンか、Subversionのトランザクション(それは普通はリビジョンとな るべきものです)のどちらかをあらわし、リビジョン32の /foo/bar と、リビジョン98の同じパスとの間の違いを 理解するのに必要になる三次元コンテキストを用意します。図 8.2. 「バージョン化した時刻—第三の次元!」 はSubversionファイルシステムの宇宙に 追加された次元についてのリビジョン履歴をあらわしています。

図 8.2. バージョン化した時刻—第三の次元!

以前指摘したように、libsvn_fs API は他のファイルシステムと見かけは よくにているが、このすばらしいバージョン管理能力だけは例外です。 それはバージョンファイルシステムに興味のあるすべてのプログラマによって 利用できるように設計されました。偶然の一致ではありませんが、 Subversion自身もその機能に興味があります。しかし、ファイルシステムAPI は基本的なファイルとディレクトリのバージョン管理をサポートしていますが Subversionはさらに多くを要求します—そしてそれはlibsvn_repos が 提供するものです。

Subversionリポジトリライブラリ(libsvn_repos)は基本的には ファイルシステム機能のまわりにあるラッパーライブラリです。この ライブラリはリポジトリレイアウトの作成、ファイルシステムの初期化を 正しく実行すること、などに責任を持ちます。Libsvn_repos はまた フックを実装します—特定の処理が実行されるときにリポジトリの コードによって実行されるスクリプトです。このようなスクリプトは 通知、認証、あるいはリポジトリ管理者が望むようなさまざまな 目的にとって役に立つものです。このタイプの機能と、リポジトリライブラリ によって提供されるほかのユーティリティーはバージョン化ファイルシステム の実装に強く関連しているわけではありません。それが独自のライブラリとして 実装された理由です。

libsvn_repos APIを使おうとする開発者には、それがファイルシステムインターフェース に対する完全なラッパではないことがわかるでしょう。つまり、 ファイルシステム操作の一般的なサイクルにある主要なイベントに ついてだけリポジトリインターフェースによってラップされます。 その中のいくつかは、Subversionトランザクションの生成やコミット、 リビジョン属性の修正などです。このような特定のイベントはそれに 関連したフックがあるため、リポジトリ層によってラップされます。 将来的には他のイベントもリポジトリAPIによってラップされるかも 知れません。しかし、残りのファイルシステムの作用のすべては libsvn_fs API 経由で直接実行されます。

たとえば、ディレクトリが追加されるファイルシステムの新しい リビジョンを作るための、リポジトリとファイルシステムインターフェース について、使い方を説明したコードがあります。 この例で(そして、この本全体を通じてすべてのほかの例でも)、 SVN_ERR() マクロは単にラップした関数からの 失敗した場合のエラーコードのチェックです。そしてそのようなもの があればそのエラーを返します。

/* Create a new directory at the path NEW_DIRECTORY in the Subversion
   repository located at REPOS_PATH.  Perform all memory allocation in
   POOL.  This function will create a new revision for the addition of
   NEW_DIRECTORY.  */
static svn_error_t *
make_new_directory (const char *repos_path,
                    const char *new_directory,
                    apr_pool_t *pool)
{
  svn_error_t *err;
  svn_repos_t *repos;
  svn_fs_t *fs;
  svn_revnum_t youngest_rev;
  svn_fs_txn_t *txn;
  svn_fs_root_t *txn_root;
  const char *conflict_str;

  /* Open the repository located at REPOS_PATH.  */
  SVN_ERR (svn_repos_open (&repos, repos_path, pool));

  /* Get a pointer to the filesystem object that is stored in
     REPOS.  */
  fs = svn_repos_fs (repos);

  /* Ask the filesystem to tell us the youngest revision that
     currently exists.  */
  SVN_ERR (svn_fs_youngest_rev (&youngest_rev, fs, pool));

  /* Begin a new transaction that is based on YOUNGEST_REV.  We are
     less likely to have our later commit rejected as conflicting if we
     always try to make our changes against a copy of the latest snapshot
     of the filesystem tree.  */
  SVN_ERR (svn_fs_begin_txn (&txn, fs, youngest_rev, pool));

  /* Now that we have started a new Subversion transaction, get a root
     object that represents that transaction.  */
  SVN_ERR (svn_fs_txn_root (&txn_root, txn, pool));
  
  /* Create our new directory under the transaction root, at the path
     NEW_DIRECTORY.  */
  SVN_ERR (svn_fs_make_dir (txn_root, new_directory, pool));

  /* Commit the transaction, creating a new revision of the filesystem
     which includes our added directory path.  */
  err = svn_repos_fs_commit_txn (&conflict_str, repos, 
                                 &youngest_rev, txn, pool);
  if (! err)
    {
      /* No error?  Excellent!  Print a brief report of our success.  */
      printf ("Directory '%s' was successfully added as new revision "
              "'%ld'.¥n", new_directory, youngest_rev);
    }
  else if (err->apr_err == SVN_ERR_FS_CONFLICT)
    {
      /* Uh-oh.  Our commit failed as the result of a conflict
         (someone else seems to have made changes to the same area 
         of the filesystem that we tried to modify).  Print an error
         message.  */
      printf ("A conflict occurred at path '%s' while attempting "
              "to add directory '%s' to the repository at '%s'.¥n", 
              conflict_str, new_directory, repos_path);
    }
  else
    {
      /* Some other error has occurred.  Print an error message.  */
      printf ("An error occurred while attempting to add directory '%s' "
              "to the repository at '%s'.¥n", 
              new_directory, repos_path);
    }

  /* Return the result of the attempted commit to our caller.  */
  return err;
} 

このコードで、リポジトリとファイルシステムインターフェースの両方に 対する呼び出しがあります。svn_fs_commit_txn()を 使ってトランザクションを簡単にコミットできます。しかし、 ファイルシステムAPIはリポジトリライブラリのフックの仕組みについては 何も知りません。もしSubversionリポジトリにトランザクションをコミット するたびに自動的にある種の非Subversion的な作業を実行させたい場合、 (たとえば、開発者メーリングリストにそのトランザクションで起きたすべて 変更を説明するメール を送信する、など)、その関数のlibsvn_reposで ラップされたバージョンを使う必要があります— svn_repos_fs_commit_txn()。 この関数は実際にはもし存在すれば、最初に「pre-commit」フックスクリプトを実行し、 それからトランザクションをコミットし、最後に「post-commit」フックスクリプト を実行します。フックは、実際にはコアのファイルシステムライブラリ自身 に含まれない特別の報告の仕組みを用意します。 (Subversionのリポジトリフックについての詳細はフックスクリプト項を見てください)。

フックの仕組みは、残りのファイルシステムコードから 独立したリポジトリライブラリの抽象化が一つの理由です。 libsvn_repos API はほかにもいくつかの重要なユーティリティーを Subversionに提供しています。これには以下のようなものがあります:

Subversionが進化し続けるにつれて、リポジトリライブラリは 増えつづける機能と設定可能なオプションをサポートを提供する ために，ファイルシステムライブラリとともに大きくなり続ける でしょう。

もしSubversionリポジトリ層が、「通信路のもう一方の端点」 であるなら、リポジトリ アクセス層は、その通信路そのもののです。クライアントライブラリとリポジトリ の間でデータを相互変換することが課せられたこの層は libsva_raモジュールローダ ライブラリ、そのRAモジュール自身(現在のところ、libsvn_ra_dav, libsvn_ra_local,そして libsvn_ra_svnを含みます)、そして一つ以上の RA モジュールに必要となる追加 のライブラリ、たとえば、libsvn_ra_dav が通信するための、mod_dav_svn Apache モジュールを含みます。mod_dva_svn モジュールを利用しないときには、 libsvn_ra_svn のサーバであるsvnserveが通信します。

Subversionは、リポジトリリソースを特定するのに URLを利用するので、 URLスキーマのプロトコル部(普通は、file:, http:, https:, あるいは svn:) はどの RA モジュールが通信を処理するか を決めるために使われます。それぞれのモジュールは、プロトコルのリスト を登録しますが、それはどうやって「話せば」良いかを知っているので、 RA ローダが実行時にどのRAモジュールをその処理のために利用するかを 決定することができます。どのRAモジュールがSubversionコマンドライン クライアントに利用可能かを決定することができ、svn --version を実行することで、どのプロトコルはサポートしていないと言ってくるか を知ることができます。:

$ svn --version
svn, version 1.2.3 (r15833)
   compiled Sep 13 2005, 22:45:22

Copyright (C) 2000-2005 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

クライアント側から見ると、Subversionの作業コピーは すべての処理が起こる場所です。クライアント側ライブラリによって 実装される機能は、作業コピーの管理というただ一つの目的のために 存在します—ローカルな場所に何らかの形で提供される ファイルと他のサブディレクトリのあるディレクトリが、一つ以上の リポジトリ位置を「反映した」ものとし、リポジトリアクセス層との間の 変更を伝えたりします。

Subversionの作業コピーライブラリ、libsvn_wc は作業コピー中の データの管理に直接の責任を負います。これをやるために、このライブラリ は特別なサブディレクトリの中にそれぞれの作業コピーについての管理情報 を格納します。このサブディレクトリは.svn という 名前ですが、どの作業コピー中にも存在し、管理に関係した動作を するための状態を記録し、作業スペースを確保するためのさまざまな ファイルやディレクトリを含んでいます。CVSになじみのある人なら、 この.svn サブディレクトリは、その目的としては CVSの作業コピーにある管理ディレクトリCVS に よく似ていることがわかると思います。.svn 管理領域についての詳細は、この章の 作業コピー管理領域の内部項を参照してください

Subversionクライアントライブラリ libsvn_client は広範囲の役目を 負います。その仕事は、作業コピーライブラリの機能と、リポジトリアクセス層 の機能を結びつけることで、一般的なリビジョン制御を実行したいと思う すべてのアプリケーションに最上位のAPIを提供することです。たとえば svn_client_checkout() 関数は引数としてURLを とります。この関数は URLを RA層に渡し、特定のリポジトリに認証された セッションを開きます。それからそのリポジトリに特定のツリーを指定し、 このツリーを作業コピーライブラリに送りますが、今度はそのライブラリが 作業コピー全体をディスクに書き込みます(.svn ディレクトリを含むすべての情報)。

クライアントライブラリはどのようなアプリケーションからも利用できる ように設計されています。Subversionのソースコードは標準的なコマンド ラインクライアントを含んでいるので、そのクライアントライブラリの 上に好きなだけGUIクライアントを書くことができます。Subversionの 新しい GUI(あるいは実際には新しいクライアント)は、コマンドライン クライアントを含むダサいラッパである必要はありません。 —それは、libsvn_client API を通じてコマンドラインクライアント が使っているのと同じ機能、データ、コールバックの仕組みに完全にアクセス することができます。