SVNリポジトリをどのように構成しますか？ [閉まっている]
https://stackoverflow.com/questions/152328
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
優れているもの
A：
server:1080/repo/projectA/trunk/...
branches/branch1
branches/branch2
branches/branch3
tags/tag1/...
tags/tag2/...
server:1080/repo/projectB/trunk/...
branches/branch1
branches/branch2
branches/branch3
tags/tag1/...
tags/tag2/...
B：
server:1080/repo/trunk/projectA/...
branches/projectA/branch1
branches/projectA/branch2
branches/projectA/branch3
tags/projectA/tag1/...
tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
branches/projectB/branch1
branches/projectB/branch2
branches/projectB/branch3
tags/projectB/tag1/...
tags/projectB/tag2/...
どのリポジトリ構造を使用していますか？
解決
他のヒント
Aを使用します。もう1つが意味をなさないためです。 ＆quot; project＆quot; SVNに関しては、必ずしも単一のプロジェクトではなく、一緒に属する複数のプロジェクト（つまり、Visual Studioのソリューションに入れるもの）である場合があります。これにより、関連するものはすべてグループ化されます。特定のプロジェクトのすべてのブランチ、タグ、およびトランク。私にはぴったりです。
ブランチ/タグによるグループ化は、私には意味がありません。なぜなら、異なるプロジェクトのブランチには、それらがすべてブランチであることを除いて、共通点がないからです。
しかし、結局のところ、人々は両方の方法を使用します。あなたが好きなことをしてください、しかしあなたが決めたとき、それにとどまるようにしてください：）
追加として、顧客ごとに個別のリポジトリがあります。つまり、顧客のすべてのプロジェクトは同じリポジトリにあります。このようにして、例えば単一の顧客のバックアップを一度に作成するか、SVNと戦わずに顧客が所有するもののソースコードを彼に提供します。
オプションCを提案します：
server:1080/projectA/trunk/...
branches/branch1
branches/branch2
branches/branch3
tags/tag1/...
tags/tag2/...
server:1080/projectB/trunk/...
branches/branch1
branches/branch2
branches/branch3
tags/tag1/...
tags/tag2/...
別々のリポジトリに別々のプロジェクトを保持することを好みます。 svn：externals を使用すると、共有されているコードライブラリプロジェクトを簡単に管理できます。 2つ以上のアプリケーションプロジェクト間。
設定Bを使用します。複数のプロジェクトを一度にチェックアウト/タグ付けする方が簡単です。 svn 1.5では、スパースチェックアウトで可能ですが、ワンクリック操作ではできません。 一部のプロジェクトの間に隠れた依存関係がある場合は、設定Bを使用します。
使用
/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags
後悔し始めています。それは平らでなければなりません。これは良いでしょう。
/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags
なぜですか？製品（コンポーネント、完成したソフトウェア）は永遠に続きます。プロジェクトは行き来します。昨年、製品QUUXを作成するプロジェクトチームは1つだけです。来年、そのチームは分散され、1人または2人がQUUXを維持します。来年、2つの大きなQUUX拡張プロジェクトが予定されています。
そのタイムラインを考えると、QUUXは3つのプロジェクトリポジトリに表示されるべきですか？いいえ、QUUXは特定のプロジェクトから独立しています。プロジェクトに作業成果物（ドキュメント、バックログなど）があり、それが作業を完了するための一部であるのは事実ですが、作業の実際の目標ではありません。したがって、「projectX」その素材のリポジトリ-プロジェクトの完了後に誰も気にしないもの。
私は3つのチームを持つ1つの製品に取り組みました。各プロジェクトが個別にリポジトリを管理するため、作業の調整に大きな問題があります。チーム間リリースとチーム間調整がありました。その日の終わりには、1つのソフトウェアが想定されていました。ただし、ご想像のとおり、奇妙な重複と冗長性を備えた3つのソフトウェアでした。
個人的には、次のリポジトリ構造を使用しています：
/project
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
これらのディレクトリの使用方法を示す図もあります。また、私が使用している特定のバージョン番号アプローチもあります。リポジトリの構造化において重要な役割を果たします。最近、ソフトウェア構成管理専用のトレーニングを開発しました。このトレーニングでは、バージョン番号付けのアプローチと、このリポジトリ構造が最適である理由について説明します。 プレゼンテーションスライドをご覧ください。
また、回答もあります「複数のSVNリポジトリと単一の会社のリポジトリ」に関する質問。質問でリポジトリ構造化のこの側面に取り組む限り、役に立つかもしれません。
