OK、単一プロジェクトのリポジトリのトランク/タグ/ブランチのことを理解しました。
ここで、メイン プロジェクトと、いくつかの小さな補助モジュール/プラグイン/ツール/スクリプトなどがあるとします。初期段階では、多くの名前変更、再編成などがあり、それらのいくつかはどこにも行かないために早期に死亡します。 . 組織がかなり安定するまで、特定のモジュールをトランクに貼り付けても意味がありません。(その時点で、トランクへのコピーはsvn設計ごとに「安価」です)
開発プロセスの早い段階で小さなモジュール (「FooModule」など) を配置するのに最適な場所はどこでしょうか?
同様の方法でSubversionリポジトリを整理した経験のある人はいますか? 何があなたのために働いたのですか？
これは非常に興味深い質問です。適切に開始することには多くの利点があります (モジュール化、低カップリングなど)。とにかく、これは私が始める方法です：
1）すべてをトランクに入れます：
http://svn/application/trunk/application
2) 可能であれば、コードをモジュールに分割するために早期に開始します
http://svn/application/trunk/application1
module1
module2
3) モジュールが安定している場合は、それをアップストリームに独自のリポジトリに移動します。
http://svn/module1/trunk
4) 最後に、いくつかの安定したモジュールとアプリケーションがある場合、最終的には次のようになる可能性があります
http://svn/application1/trunk
http://svn/application2/trunk
http://svn/module1/trunk
http://svn/module2/trunk
各アプリケーション/モジュールには独自のリリース サイクルがあります。
別の方法として、Spring Framework が何を行っているかを確認することもできます (私に尋ねれば、非常に素晴らしい組織です)。
http://svn/application1/trunk
http://svn/application2/trunk
http://svn/framework/trunk/module1
http://svn/framework/trunk/module2
少なくともプロジェクトの開始時には、コードを各モジュールのトランク/ブランチに分割しないことをお勧めします: ブランチを開始するとすぐに (トランクで作業していない場合)、他のモジュールのトランクの HEAD を操作することはできません。もう: すべてのプロジェクトを同時に分岐するか、特定のバージョン (SNAPSHOT ではなく 1.0) で作業する必要があります。あまり明確ではないと思いますが、別の説明が必要な場合はお知らせください。
David の投稿を編集することはできませんがsvn:externals、リリースの観点からは非常に危険です (imo)。悪夢のシナリオは次のとおりです。
svn:externalsアプリケーション内にモジュール コードがあるとします。念のため、モジュールの Subversion リビジョンが 1000 であるとします。ブランチを作成し、リリースを作成して顧客に出荷します。
時が経ち、数か月または数年後に、顧客からアプリケーションの問題を修正するよう依頼されました。ブランチをチェックアウトしsvn updatingてプロジェクトを開始します。残念ながら、リンクされたモジュールは大幅に変更され、バージョンは 23456 になりました。そして、アプリケーションはもはやコンパイルさえしません。
もちろん、あなたがしなければならないことは、svm:externals分岐したときに正確なバージョン (1000) を指すように変更することです。また、モジュールのコードを変更する必要がある場合は、リビジョン 1000 でモジュール用に作成されたブランチの先頭を指す必要があります。
多くの不必要な作業があるため、大規模なプロジェクトでエクスターナルを使用することは強くお勧めしません。
あなたが良い経験をしたことがあれば、svn:externals私はすべての耳です。
私の組織構造があなたのニーズに合っているかどうかはわかりませんが、トランク/タグ/ブランチ モデルとは非常に異なるアプローチをとっています。詳細については、http://www.mattwrock.com/post/2009/10/10/The-Perfect-Build-Pard-2-Version-Control.aspxをご覧ください。
これが私たちの構造です：
/prod
/prod/app1/20090903
/prod/app1/20090917
/prod/app2/20090903
/sandbox
/sandbox/users/mwrock
/staging
/staging/app1
/staging/app2
/trunk
/trunk/libraries
/trunk/desktop
/trunk/docs
/trunk/services
/trunk/sql
/trunk/testing
/trunk/thirdparty
/trunk/web
ここには、次のルート フォルダーがあります。
Trunk : メインラインへの統合に適した最新のコード リビジョンを保持します。すべてのプロジェクトとチームが共有する 1 つのトランクがあります。開発者は、この 1 つのフォルダーをチェックアウトするだけで、必要なものがすべて揃っています。
サンドボックス: これらは、トランクにマージして戻す準備ができるまで、トランクとは別に保持したい、長時間実行される変更を分岐するために使用される個人開発領域です。
ステージング: これは最終的な QA/UAT エリアです。開発が安定し、最終テストの準備が整ったと考えられると、トランクがここにコピーされます。これにより、他のチームによってトランクにコミットされた開発からリリースが保護されます。リリースがこの段階にある場合、コード ベースに他の誰かから未知のコミットが入るのは望ましくありません。
Prod : これには製品リリースが含まれます。各アプリケーションには、prod の下に独自のフォルダーがあり、各リリースには、リリースの日付にちなんで名付けられたフォルダーがあります。ステージング ブランチはデプロイ時にこれらのリリース タグにコピーされ、リリース時のコードのスナップショットを表します。prod エリアは、正確に何がいつリリースされたかの歴史的記録です。
/branches/dev/FooModuleIMHOの最初からトランクに入れたくない場合は、これが最も賢明なアプローチです。それが開発ブランチの目的です (ただし、通常は逆で、コードはそこでトランクからコピーされ、最終的にトランクに戻ります)。
あなたが与えた他の2つの例のような珍しいルートパス名は絶対に避けます。Subversion を使用したバージョン管理で、さらに考慮すべき点を見つけることができます。
私自身がこの種のことに取り組んだときは、完全に別のリポジトリを使用して、不要なリビジョンでメイン リポジトリが乱雑になるのを防ぐ傾向があります。
私は、アプリごとにトランク、タグ、ブランチを用意するのが好きです。このような設計では、サンドボックスでやりたいことが何でもできます。
app1/
trunk/
tags/
branches/
app2/
trunk/
tags/
branches/
sandbox/
trunk/
tags/
sure_you_could_keep_the_parallelism_up_here_but_is_there_really_any_need/
人々は、この方法やルート レベルのトランク、タグ、ブランチの方法の長所と短所について口論しますが、この方法の大きな利点の 1 つは、マージとチェックアウトの手間がはるかに少ないことです。
(多くの人は、プロジェクトがアプリケーション間でコードを共有しているのを見て、この構造を見落としています。そのようなコード共有が必要な場合、svn:externals を使用してある程度の成功を収めています。これの本当に素晴らしい点は、共通ライブラリへの破壊的な変更でさえ問題にならないということです。外部を使用してタグにリンクすると、共通ライブラリが機能することがわかっている時点でフリーズします。)