Subversionのリポジトリ構成

なんか今更感のあるネタですが書いてみたいと思います。大きく分けて３パターンあると思います。

1. 単一リポジトリ単一trunk型

http://.../svn/ProjectA/
    |
    |--------trunk/
                 |--------ComponentA/
                 |--------ComponentB/
    |--------branches/
                 |--------Patch_1.0
                            |--------ComponentA/
                            |--------ComponentB/
    |--------tags/
                 |--------1.0
                            |--------ComponentA/
                            |--------ComponentB/

いちばんオーソドックスなパターンといえるでしょう。個人的には好みです。
ComponentAとComponentBのバージョンを同期させる必要があるならこの構成でしょう。
Redmin使ってるならhttp://.../svn/ProjectA/trunk/ComponentAをプロジェクトに割り当てるんでしょう。たぶん。

2. 単一リポジトリ複数trunk型

http://.../svn/ProjectA/
    |
    |--------ComponentA/
                            |--------trunk/
                            |--------branches/
                            |--------tags/
    |--------ComponentB/
                            |--------trunk/
                            |--------branches/
                            |--------tags/

これも割と見るタイプです。ComponentAとComponentBのバージョンを同期させる必要が無いならこの構成になるのかなと。
Apahce(https://svn.apache.org/repos/asf/)もこのタイプという気がします。Apahceの場合は、第一階層がプロジェクト、第二階層がサブシステム、第三階層がtrunk, tags, branchesとなってますね。

3. 複数リポジトリ型

http://.../svn/ComponentA/
    |
    |--------trunk/
    |--------branches/
    |--------tags/

http://.../svn/ComponentB/
    |
    |--------trunk/
    |--------branches/
    |--------tags/

Seasar(https://www.seasar.org/svn/)がこのタイプですね。

ComponentAとComponentBのバージョンを同期させる必要が無いならこの構成でもいい気がします。リビジョン番号が混ざらないし。Trac 0.12のマルチリポジトリ使うならこの構成になるのかなと。

で、RedmineやTracとの連携も含めて考えても、どの構成にするかはComponentAとComponentBの依存関係次第かなと。

例えばComponentAが無いとComponentBがコンパイルできないようなケースなら一般的には上記1のタイプかなと思います。ただTrac 0.12のマルチリポジトリ使うなら3になるでしょう。個人的には1のほうが自然な気がしますがどうなんだろ。
普通に考えると1の構成にしてRedmineのプロジェクトを複数にすればいい気もしますが、Redmineユーザでもマルチリポジトリは欲しいと思っているようです。プロジェクトを分けると関連が薄くなりすぎるからのようです。難しいですね。

それ以外にはComponentAがコアでComponentBがプラグインのようなケースなら2のタイプという気がします。プラグインごとにバージョンを同期させなくてもいいよねっていう発想です。