7

プロジェクトを、トランク、ブランチ、タグのサブディレクトリを含む SVN ディレクトリとして定義します。

プロジェクトを 2 つに分割したり、複数のプロジェクトを 1 つに統合したりする時期を決定する際に、どのような基準を使用しますか? - 共通のソースとリソースの共有プロジェクトを使用して、「プロジェクト」ごとに 1 つのアプリを使用しますか? - アプリのすべてのソースとリソースを含む 1 つの大きな「プロジェクト」?

単一プロジェクトまたは複数プロジェクトの両方にプラスとマイナスがあります。私たちは単一のプロジェクトに向かって進んでおり、これが正しいアプローチかどうかを判断しようとしています.

プロジェクトを分割すると、スイートのさまざまな部分に変更を組み込む方法をより細かく制御できます。共通ライブラリはバージョンにすることができ、さまざまなアプリケーションが特定のバージョンを使用することを選択できます (maven dep 管理アプローチ)。

また、プロジェクトを分割すると、複数のクラス階層が作成されるため、コード全体が理解しにくくなり、コードの重複が発生する可能性があります。全体の構造とコンポーネント間の関係を適切に設計することが、このコストを管理するための鍵になると思います。

統一されたプロジェクト アプローチにより、開発者はワークスペースを設定しやすくなり、単一のクラス階層が提供されます。これは諸刃の剣であり、開発者にさらに多くの情報を投げかけます (クラスが多すぎて理解できません)。

では、結合する場所と分割する場所を決定しようとするとき、どの経験則を使用しますか?

4

10 に答える 10

5

1 つのアプリに関連するすべてのプロジェクトを 1 つの SVN Rep 内に配置したのは、メンテナンスを容易にするためであり、アプリのコード ベースを 1 つのリポジトリのみに集中させ、アプリのさまざまなリソース間の相互依存関係を管理する機能も備えています。

通常、リソースはトランク内のさまざまなフォルダーに分類されます。その分類は、主に機能/モジュールのグループ化または階層化されたグループ化 [DAL、BLL、GUI など] に基づいています。それは完全にコードの構造次第です。お役に立てれば。

于 2009-05-01T18:21:33.850 に答える
4

SVN Bookには、両方のアプローチに関する良い議論があります。

最終的には、リポジトリ ユーザーにとってより自然に感じられるものを選択します。

個人的には、単一の SVN トランク/タグ/ブランチ アプローチを支持しており、実際のすべてのコード プロジェクトをそれらのフォルダー内の独自のフォルダーに配置しています。

ただし、より大きなコード ベース (単一のソリューションの一部である 3 ～ 4 個の小さなプロジェクトしか管理していない) の場合は、分割アプローチに変更することを強く検討します。

于 2009-05-01T18:18:33.700 に答える
3

プロジェクトのサイズに応じて、個別のプロジェクトと結合されたプロジェクトの両方を使用します。大規模なプロジェクトの場合、それぞれが個別のリポジトリにあり、独立したビルドおよび展開手順があります。小規模なプロジェクトの場合、それらを格納するための「ツール」リポジトリがあり、各サブプロジェクトはルートのサブディレクトリになります。

私はまた、人々がテスト プログラムの 1 回限りのユーティリティ、またはソース管理と集中バックアップの恩恵を受ける可能性のあるその他のものを保存できる「個人用」リポジトリを維持していますが、独立したプロジェクトとしては属していません。

于 2009-05-01T18:21:49.043 に答える
2

有機的に成長します。事前最適化はすべての悪の根源である、とダイクストラはかつて言った。また、YANGI（あなたはそれを必要としないでしょう）を覚えておいてください。

すべてのアプリケーションは、トランク/タグ/ブランチを含む独自のフォルダーを取得します。アプリケーション内のプロジェクトが非常に大きくなると、プロジェクトはそれ自体の別のフォルダーにプッシュされ、ビルド時にアプリケーション（またはsvn：externals）にリンクできます。

とはいえ、プロジェクト要件が10人の開発者によって作成された複雑なアプリケーションを開発することであり、あなたがゲートキーパーまたはビルドマスターである場合は、より複雑な代替案を検討できます。

于 2009-05-01T21:16:32.760 に答える
2

私は別々のプロジェクトを使用し、それらを組み合わせて svn:externals を介してソリューションを形成します。

于 2009-05-01T18:18:00.690 に答える
2

プロジェクトごとに個別にデプロイされる 1 つのアプリ / モジュール。単一のプロジェクトを使用すると、他のモジュールの安定した実装に依存するモジュールで Maven 風の依存関係管理が必要であることがわかった場合に、リリース サイクルを導入することが困難になります。また、依存関係グラフを正気 (tm) に保つために因数分解するのではなく、他のアプリからのランダムな有用なコードを直接使用するだけの人につながる可能性もあります。

統合テストは、適切なテスト スイートと明確に定義された CI プラクティスを使用して行う必要があります。一部が壊れた場合にコードの半分が突然失敗することに依存するのではありません。

単一の uber-project を持つことのもう 1 つの問題は、単一のモジュールでのみ作業する git-svn ユーザーにとってかなり面倒なことです。

于 2009-05-01T18:22:25.830 に答える
1

複数のプロジェクトにまたがる Subversion リビジョン番号 を確認することをお勧めします。

于 2009-05-01T21:22:36.130 に答える
1

入力していただきありがとうございます。すべての回答に重要なポイントがあると思うので、回答を「選択」しません。時期尚早の最適化を回避することは、当面レイアウトをできるだけシンプルに保つことと同様に重要なようです。アプリを含む単一のプロジェクトに移行するのは、90% の時間ですべてを一緒にリリースするためです。したがって、プロジェクトごとに 1 つのアプリで問題を複雑にすることは意味がないようです。Maven に移動する場合でも、特定のバージョンのすべての Maven アーティファクトが同じブランチから作成される可能性があります。SVN 履歴と魚眼レンズを使用して正気を保つ必要がある場合は、後でいつでも変更できます。

ソースをリファクタリングするのと同じように、ソース レイアウトをリファクタリングします。プロジェクトが周囲と依存関係の状況から「悪臭」を放ち始めたら、それを分割しますが、それ以前ではありません。私はおそらく、空間ではなく時間での胴回りを使用します: 構築とテストの時間、チェックアウトの時間. 10 分未満でチェックアウトでき、30 分未満でビルド/テストできる 1GB のツリーがある場合、その一部を頻繁にリリースする必要がない限り、実際に分割する必要はありません。

それでは、ご意見をお寄せいただきありがとうございます。私のチームへの質問を組み立て、オプションを評価するのに非常に役立ちました。

于 2009-05-04T13:12:27.093 に答える
1

ここには「良い」答えはありませんが、1 つまたは 2 つのプロジェクトを含む SVN リポジトリと、100 を含むその他のリポジトリとを区別する必要があると思います。

私は VSS から移行された SVN リポジトリを維持しています。その中には数百の「プロジェクト」があり、トランク/ブランチ/タグ構造に沿って編成されたものはありません (実際、この構造は本当に不要で役に立たないと思います。しばらく SVN を使用していましたが、2 つまたは 3 つのプロジェクトを 1 つの変更としてタグ付けする必要がある場合には、まったく役に立ちません)。

私たちは、管理しているすべてのソフトウェアのプロジェクト ディレクトリを管理しています。その下には、構成用のサブディレクトリとソース用のサブディレクトリがあります。それらの下には製品のバージョン番号があります - 効果的にトランクの概念を捨てているので、タグディレクトリしかありません - 最大の番号はトランクです (プロジェクトの複数のバージョンを同時にサポートする必要があるため、これを行う必要があります)。マージは必要に応じて行われるので、プロジェクト A のバージョン 3.0 のバグを更新すると、これらの変更をバージョン 4.0 と v5.0 にマージします。

1 つまたは 2 つのプロジェクトだけでレポを作成する場合、ブランチ/タグ構造を保持したくなるかもしれませんが、その一方で、おそらくメイン ツリーでディレクトリを明示的に保持するでしょう (そうしなかったと仮定します)。定期的にタグ付けするのに十分な頻度でリリースします)(リビジョン番号を「タグ」として使用し、そこにバイナリを保存します。したがって、特定の古いリビジョンを取得する必要がある場合は、ログを見て正しいバイナリを取得できます)

現在、revnum が 300,000 を超えている 10Gb のレポがあり、古いコードと新しいコードがたくさんあることを考えると、管理は驚くほど簡単です。私は他の人に構造をお勧めし、再びそれを使用します.

ちなみに、タグ dir が機能しないもう 1 つの理由は、バグや変更要求があるたびに、どんなに小さなものでもリリースするためです。タグ ディレクトリは、しばらくすると管理できなくなります。これが revnum をタグとして使用する理由です。これをバグ トラッカーと関連付けて、人間が読みやすいようにすることもできます。

大まかに要約すると、v1 と v2 が製品バージョンである次のようなディレクトリ構造があります。

maint/source/v1.0/projectA
maint/source/v1.0/projectB
maint/source/v2.0/projectA
maint/source/v2.0/projectB
etc

明らかに、「ソース」の下にブランチ ディレクトリを配置し、各サブプロジェクトの下にブランチ/タグを配置することもできますが、2 つのサブプロジェクトを 1 つの変更要求としてリリースする必要がある場合は注意が必要です (よくあることです)。ソース ディレクトリの下にサブディレクトリにタグを付けると、サブプロジェクトが 1 つだけ変更されたときに、すべてにタグを付けることになります (各サブプロジェクトを個別に追跡するという要件には適合しません)。

于 2009-05-04T13:50:56.470 に答える
1

プロジェクトごとに個別の SVN リポジトリを保持します。あなたが望む最後のことは、マージの日を持つことです

于 2009-05-01T18:24:38.693 に答える