ここまでで、Subversionは非常に柔軟なシステムであることがおわかり いただけたかと思います。ディレクトリのコピーという同じ基本的な 仕組みの上にブランチもタグも実装しており、ブランチもタグも普通の ファイルシステムの空間の中にあるので、多くの人々はSubversionの 仕組みにびっくりします。それは柔軟すぎるくらい です。この節では時間経過と共にどのようにデータを配置し管理するのが 良いかについて、少し説明します。
リポジトリの編成にはある程度、標準化された、おすすめの方法が あります。ほとんどの人々はtrunkディレクトリ に開発の「主系」、ブランチのコピーがあるbranches ディレクトリ、そしてタグのコピーがあるtagsディレクトリ を入れます。リポジトリがただ一つのプロジェクトを含む場合には しばしば、この三つのディレクトリをリポジトリ最上位に作ります:
/trunk /branches /tags
リポジトリが複数プロジェクトを含む場合は、プロジェクトごとに レイアウトをインデックス化します (「プロジェクトルート」についての詳細は リポジトリ構成の計画項 を読んでください):
/paint/trunk /paint/branches /paint/tags /calc/trunk /calc/branches /calc/tags
もちろん、この標準的なレイアウトを無視してもかまいません。 あなたと、チームが最も作業しやすいように、このレイアウトは どのように変化させてもかまいません。どれを選んでもそれは 永久に固定されたものではありません。いつでもリポジトリを 再編成することができます。ブランチとタグは普通のディレクトリ にすぎないのでsvn moveコマンドを使えば 好きなように移動、名称変更ができます。あるレイアウトから別の レイアウトへの切り替えは単にサーバ側での何回かの移動の話になります。 もしリポジトリ中の編成に何か気に入らないところがあるなら、ディレクトリ に関連した小技を使ってください。
しかし、ディレクトリの移動は簡単ではありますが、ユーザのこともよく 考える必要があります。この変更は既にある各自の作業コピーの場所 を再配置します。もしユーザが特定のリポジトリのディレクトリの作業 コピーを持っている場合、あなたの svn move操作 は最新リビジョンのパスを削除してしまうかも知れません。ユーザが 次にsvn updateを実行すると、作業コピーは すでに存在しないパスを示しているとされ、新しい場所に移動する ためにsvn switchの実行を強要されてしまう でしょう。
Subversionモデルの別の良い機能としては他のバージョン 管理されたアイテムと同様、ブランチとタグは有限の種ｴ幔ｽしか持たない ようにもできることです。たとえばcalcプロジェクト の個人的なブランチ上ですべての作業が完了したとします。すべての 変更を、/calc/trunkにマージしたあとでは その個人的なブランチのディレクトリがまったく不要になります:
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch ¥
-m "Removing obsolete branch of calc project."
Committed revision 375.
これでブランチはなくなってしまいました。もちろん本当に削除された わけではありません: ディレクトリは単に HEADリビジョンからなくなった だけで、誰もわずらわせることはなくなりました。 前のバージョンを調べるためにsvn checkout、 svn switch、あるいは svn list を使えば依然として古いブランチを見ることができます。
削除したディレクトリを閲覧するだけでは不十分な場合は、いつでも 戻すこともできます。データの復活はSubversionではお手のものです。 HEADに戻したい削除ディレクトリ(またはファイル)がある場合は、単に svn copy -r を使って古いリビジョンから コピーしてください:
$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch ¥
http://svn.example.com/repos/calc/branches/my-calc-branch
Committed revision 376.
私たちの例では個人的なブランチは比較的短い生存時間を持ちます。バグを 直したり新しい機能を追加するのに利用したからです。作業が終われば、 ブランチの種ｴ幔ｽもそこで終わりです。しかし、開発内容によっては 非常に長い時間にわたって二つの「主要な」ブランチが並行して生きつづけることも あります。たとえば、安定版のcalcプロジェクトを 公にリリースするときがやってきて、そのソフトのバグをとるのには 何ヶ月かかかるとします。リリースバージョンに新しい機能を追加させたくは ありませんが、すべてのメンバーに開発を中止するように言いたくもありま せん。そこでかわりに、あなたはそれほど大きな修正は発生しない 「安定版」のブランチを作ります:
$ svn copy http://svn.example.com/repos/calc/trunk ¥
http://svn.example.com/repos/calc/branches/stable-1.0 ¥
-m "Creating stable branch of calc project."
Committed revision 377.
これで開発者は最先端の機能(あるいは実験的な機能)を /calc/trunkに追加し続けることが でき、バグフィックスだけを/calc/branches/stable-1.0 にコミットするようなポリシーで進めることができます。 つまり、メンバーがtrunk上で作業し続けるときに、バグフィックスに ついては安定版ブランチ上に持っていくことができます。安定版ブランチ が出荷されたあとでも、そのブランチを長い時間かけて保守し続ける でしょう—つまり、顧客に対してそのリリースをサポートし続ける 限り。