Subversionを使うと、あなたは情報を失うことなしにバージョン化されたファイルや ディレクトリをあちこちに移動することができますが、そうすることは、 データが特定の場所にあることを期待している、ときどきリポジトリにアクセス する人たちの作業を中断させてしまうかも知れません。先のこともちょっとは 考えてください。バージョン管理下にデータを置く前に、前もって計画を たててください。リポジトリの内容を、最初にうまく「レイアウト」 しておけば、あとで頭を抱えることがなくなります。

Subversionリポジトリを設定するときに考えておくと良いことがいくつか あります。あなたが、リポジトリ管理者としていくつかのプロジェクトのバージョン 管理システムのサポート責任者になったとしましょう。最初の判断は 複数プロジェクトに対して一つのリポジトリを使うか、プロジェクトごとに リポジトリを用意するか、その両者の折衷案でいくかです。

複数プロジェクトのために一つのリポジトリを使うことにはいくつか 利点があまりす。一番はっきりしているのは、重複した保守作業が不要だと いうことです。一つのリポジトリは、一組のフックスクリプト、一つの 定期バックアップ、Subversionのリリースが両立不可能な新しいバージョンに なったときの、一回のダンプとロード、しか必要ありません。 また、プロジェクト間のデータ移動は簡単ですし、履歴バージョン情報を 失うことなしにやることができます。

一つのリポジトリを使うデメリットは、異なるプロジェクトは異なる コミットメーリングリストを持っていたり、異なる認証、許可などが 必要であるかも知れないことです。 また、Subversionはリポジトリグローバルなリビジョン番号を使っている ことに注意してください。人によっては、変更が自分のプロジェクトに 何もないのに、他のプロジェクトが活発に新しいリビジョンを追加する ことによって、最新リビジョン番号がカウントアップされていくのが 好きではないかも知れません。

折衷策をとることもできます。たとえば、お互いに どの程度深く関係しているかによってプロジェクトをグループ化する ことができます。それぞれのリポジトリにいくつかのプロジェクトを持たせる ことで、少ない数のリポジトリを管理することもできます。この方法では データを共有したいプロジェクトは簡単にそうすることができますし、 新しいリビジョンがリポジトリに追加されると、開発者は そのような新しいリビジョンは、自分のプロジェクトか、少なくともそれに 関係しているプロジェクトの誰かがやったものだということがわかります。

リポジトリに関係してどのようにプロジェクトを編成するかを決めたあとは 多分、リポジトリ自身のディレクトリ構成を考えたいと思うでしょう。 Subversionは普通のディレクトリコピーをブランチ化にもタグ付けにも 使うので(章 4. ブランチとマージ参照)、Subversionのコミュニティ では、以下のようなディレクトリ構成を推奨しています; プロジェクトルート—プロジェクトに関連 したデータのある「最上位」ディレクトリのこと—ごとに リポジトリの場所を選択します; 次いでそのルートの 下に三つのサブディレクトリを作ります: trunk これはプロジェクトの主な開発が行われるディレクトリです; branches これは主な開発ラインから分岐したさまざまな名前の付いたブランチを作る ための場所です; tagsこれは作成され、削除される かも知れませんが、決して修正はされないようなブランチを入れるための ディレクトリです。 ^[21]

たとえば、リポジトリが以下のようであるとして:

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

それぞれのプロジェクトルートがリポジトリ中のどこにあるかは問題には なりません。もしリポジトリに唯一のプロジェクトがある場合は それぞれのプロジェクトルートを置くための論理的な場所はプロジェクト ごとのリポジトリのルートになります。もし複数のプロジェクトが ある場合は、リポジトリ内部のグループ中にそれを配置したいかも知れません、 おそらく同じサブディレクトリ中の似たような目標や共有するコードと 一緒にプロジェクトを置くか、あるいは名前の辞書順にグループ化するか、 などです。配置は以下のようになるでしょう:

/
   utils/
      calc/
         trunk/
         tags/
         branches/
      calendar/
         trunk/
         tags/
         branches/
      …
   office/
      spreadsheet/
         trunk/
         tags/
         branches/
      …

良いと思われる方法でリポジトリをレイアウトしてください。 Subversionはレイアウトの構成について何も仮定しません— Subversionは、ディレクトリであってディレクトリ以外の何者でも ありません。結局、リポジトリのレイアウトは、それを利用する人々の 必要に応じたふさわしい方法を選んでください。

リポジトリ中でのプロジェクトのレイアウトが決まったら、 そのレイアウトの形にリポジトリを構成して、プロジェクトの初期データを ロードしたいと思うでしょう。これにはいろいろな方法があります。 一つ一つリポジトリレイアウトに従ってディレクトリを 作るのに、svn mkdir コマンドを使うことができます ( 章 9. Subversion リファレンス参照)。 もっと手っ取り早いのは、svn import コマンドを 使うことです。(svn import項参照) 最初にディスクの一時的な場所にレイアウトを作っておいて、その全体を 一回のコミットでリポジトリにインポートすることができます:

$ mkdir tmpdir
$ cd tmpdir
$ mkdir projectA
$ mkdir projectA/trunk
$ mkdir projectA/branches
$ mkdir projectA/tags
$ mkdir projectB
$ mkdir projectB/trunk
$ mkdir projectB/branches
$ mkdir projectB/tags
…
$ svn import . file:///path/to/repos --message 'Initial repository layout'
Adding         projectA
Adding         projectA/trunk
Adding         projectA/branches
Adding         projectA/tags
Adding         projectB
Adding         projectB/trunk
Adding         projectB/branches
Adding         projectB/tags
…
Committed revision 1.
$ cd ..
$ rm -rf tmpdir
$

svn listコマンドでインポート結果を 確認することができます:

$ svn list --verbose file:///path/to/repos
      1 harry               May 08 21:48 projectA/
      1 harry               May 08 21:48 projectB/
…
$

骨組みとなるレイアウトができて、もし既にインポートしたい データが存在しているならそれをリポジトリにインポートすることができます。 これにも、やはりいろいろな方法をとることができます。 svn importを使うかも知れません。新しいリポジトリから 作業コピーをいったんチェックアウトして、作業コピー中でデータを移動したり 編成しなおしてから、svn add とsvn commit コマンドを使うこともできます。しかし、いったんそのような 話を始めると、もう既にリポジトリ管理については議論しません。 もし、まだsvn クライアントプログラムに なじみがないのなら、 章 3. 同伴ツアーを参照してください。