私はSVNリポジトリをセットアップする準備をしていますが、リポジトリ構造の良い例が誰かあるかどうか疑問に思っていました。私は現在考えています:
開発
..アプリケーション
....App1
......トランク
......ブランチ
......タグ
..データベース
..サードパーティ
この構造はおそらく私たちが必要とするすべてのものを保持することができますが、私はそれをもう少し細かくしたいと思います。何かご意見は?
私はSVNリポジトリをセットアップする準備をしていますが、リポジトリ構造の良い例が誰かあるかどうか疑問に思っていました。私は現在考えています:
開発
..アプリケーション
....App1
......トランク
......ブランチ
......タグ
..データベース
..サードパーティ
この構造はおそらく私たちが必要とするすべてのものを保持することができますが、私はそれをもう少し細かくしたいと思います。何かご意見は?
同様のモデルから始めましたが、少し面倒でした。主な問題は、リリース時にコードベースを分岐する場合は、コンポーネントごとに分岐を作成する必要があることです。
代わりに、次のようなスキームを検討しました。
trunk
app1
app2
lib1
lib2
branches
rc-2.0
app1, app2, lib1, lib2...
some-devs-branch
app1, lib2
tags
release-1.0
app1, app2, lib1, lib2...
サードパーティのもののために完全に別のリポジトリを持っているのが好きです。小豆の本から完全なベンダーブランチ戦略を実装することを計画していない限り、これはうまく機能します。
私たちもこれに苦労してきました。
一部の共有ライブラリが複数のアプリケーションの一部になり、すべてを同じバージョンにしたい場合は、それほど時間はかからないことがわかりました。したがって、私たちはすべてのことを1つの再投稿にまとめることにしました。私たちはこの方法で2年以上取り組んできましたが、一緒に作業するのはとても良いことです。
すべての構成には長所と短所がありますが、完全なリポジトリを1つ持つことで、(ほぼ)すべてのファイルを適切なバージョンでまとめることができます。複数のトランクを使用する場合、仮想フォルダまたはリンク(用語を忘れてしまいました)を使用して相互にリンクさせるためのトリックがありますが、元の状態に戻すのは非常に困難です。
各構成には長所と短所があることを覚えておいてください。ただし、大企業ではない場合は、すべてを1つの親フォルダーを持つ単一のリポジトリに配置することをお勧めします。
私の現在のアプローチは、論理的なアプリケーションの境界でシステムをすべて1つのリポジトリの下で壊すことです。
たとえば、テストスイートとデータベースも備えているサービスを想像してみてください。
/project1/application1/
trunk/
Src
Test
Database
tags/
branches/
application2/
trunk/
Src
Test
tags/
branches/
これにより、複数のアプリケーションをプロジェクトに関連付けることができますが、「論理的な」アプリケーション境界ごとにリリース制御を処理できます。リリースコントロールに必要な場所/内容を検討し、それらをブランチ/タグ/トランク構造の場所として設定します。
リポジトリ全体のルートにある単一のtrunk/branchs / tagsフォルダーは好きではありません。トランク全体をチェックアウトしたくないし、結果としてブランチの部分的なチェックアウトを台無しにしたくないからです。(あなたは同意しないかもしれません、そしてあなたのマイレージは変わるかもしれませんなど)
SVNは、特定の時間にソースツリーの「スナップショットインタイム」を取得するためのタグを提供します(リリースなどに使用できます)。
ただし、リポジトリを「より細かく」する場合は、複数のリポジトリを設定することを検討する必要があります。
もちろん、「トランク」フォルダ内で、ソースコード管理を使用しなかった場合と同じように通常のディレクトリ階層を設定する必要があります。
個別の「ソリューション」ごとに、常に個別のSVNリポジトリを作成します。このリポジトリには、単純なトランク、ブランチ、およびタグの構造があります。
依存するフレームワーク(ソースコードを制御する場合)には、独自の個別のリポジトリがあります。通常は、バイナリを使用するプロジェクトに(特定のバージョンの)バイナリを含めるだけです。
すべてに対して単一のリポジトリがあるということは、巨大なリポジトリが非常に速く完成する可能性が非常に高いことを意味します。つまり、物事が遅くなり、追跡も少し難しくなる可能性があります。明らかに、それはあなたの正確なユースケースに依存しますが、個人的にはプロジェクトごとのリポジトリを選び、必要に応じてsvn:externalsを使用します。
実際、可能であれば、SVNを介した分散VCSを選択しますが、それぞれに...