SVN標準ディレクトリ構成 - atsukanrockのブログ

はじめに

SVNの標準的なディレクトリ構成の良さが、やっと理解できたのでメモしておく。

上記についての解説は、インターネット上にたくさんあるが、それでは私には良さが理解できなかった。だが、SVN自体のリポジトリ（SVNで管理されている）を見て、その良さを理解できた。『*The* Subversion Repository』を参照のこと。『README』を読むと、基本的なことがわかる。

ディレクトリ構成図

SVN自体のリポジトリの、ディレクトリ構成の一部を以下に抜粋する。末尾が「/」はディレクトリ、それ以外はファイルを表す。

/
  + README
  + branches/
  |   + 1.0.x/
  |   + 1.4.x/
  |   + 1.4.x-r24119,r24121/
  |   + 1.5.x-issue2489/
  |   + arterm-soc-work/
  |   + issue-2382/
  + tags/
  |   + 0.10.0/
  |   + 1.0.0/
  |   + 1.0.0-beta1/
  + trunk/

REAMEの和訳と補足

各ディレクトリ、およびファイルの意味、および特徴を示す。以下で、補足は私の想像であることに注意する。

/trunk/

常に最新のソースコードを格納する。

/branches/

さまざまなbranchを格納する。たとえ、branchでの変更が一部のサブディレクトリだけであっても、branchはtrunkの完全なコピーとする。一般的に、branchでの変更がtrunkにマージされたら、そのbranchは削除される。

（以下、補足）
ただし、SVN自体のリポジトリを見てもわかるように、過去にリリースされたバージョンのメンテナンス用branchは例外であり、削除されないはずである。

/tags/

リリースのスナップショット（以降「tag」）を格納する。運用ルールとして、tagが一度作成されたら、その内容を一切変更しない。もし変更が必要になったら、branches/に移動させて、そこで行う。

補足

/

SVN自体のリポジトリでは、リポジトリのroot直下にtrunk/、branches/、tags/を配置しているが、root直下である必要はない。1つのリポジトリで複数のプロジェクトを管理しても当然よくて、rootから何階層でもサブディレクトリを作成してよい。プロジェクトのルートとなるディレクトリ直下に、trunk/、branches/、tags/のセットを作成すればよい。

/README

SVN自体のリポジトリのように、trunkのコピーの単位の外に、readmeファイルを配置するとわかりやすいと思う。readmeファイルを配置したディレクトリの、運用ルールなどを記述するとよい。

/branches/1.0.x、/branches/1.4.x

それぞれ、Subverionのバージョン1.0、1.4に対するメンテナンス用branchだろう。

おそらく、マイナーバージョンが同じリリースは、互換性を保つようにしているのだと思う。つまり、基本的にはバグフィックスリリースだろう。互換性がないリリースは、マイナーバージョンをインクリメントしているのではないか。

これらは、削除されないbranchだと思う。

/branches/1.4.x-r24119,r24121/、/branches/1.5.x-issue2489/

それぞれ、branch「/branchees/1.4.x/」、「/branchees/1.5.x/」から派生したbranchだと思われる。

branchから派生したbranchには、派生元のbranchの名称をプレフィックスとして付加するという運用ルールなのではないか。たしかにわかりやすい。

これらは、将来的に役目を終えた時点で削除されるbranchだと思う。

/branches/arterm-soc-work/、/branches/issue-2382/

それぞれ、trunkから派生したbranchだと思われる。

trunkから派生したbranchには、プレフィックスを付加しないという運用ルールなのではないか。これで、branchから派生したbranchと見分けがつく。

これらは、将来的に役目を終えた時点で削除されるbranchだと思う。

/tags/0.10.0/、/tags/1.0.0/、/tags/1.0.0-beta1/

それぞれ、SVNのバージョン0.10.0、1.0.0、1.0.0 beta1のスナップショットだろう。

SVN自体のリポジトリでは、tags/にはリリースのtagしか格納されていない。しかし、我々の普段の開発を考えると、リリースがなくてもtagを作成したいタイミングは多々ある。リリースがなくてもtagを作成してよいと思う。ただし、tagの命名には注意が必要だろう。理由は、tagはtrunkからもbranchからも作成されるためだ。tagの基となったのがtrunkなのか、それともbranchなのか、tag名から一目で判断できた方がわかりやすくてよい。

tag名については、どんな場合でも適用できる万能の命名規約を作るのは難しい。理由は、バージョニングポリシーがプロジェクトごとに異なるためだ。プロジェクト発足時には、バージョニングポリシーとbranch名やtag名の命名規約を、速やかに決定すべきだろう。