5

複数のプロジェクトがある場合、デフォルトで通常推奨されるsvnリポジトリ構成は次のようになります。

root/projectA/(trunk, branches, tags)
root/projectB/(trunk, branches, tags)
...

私たちのプロジェクトには多くの相互依存関係があり、内部プロジェクトを参照するdllを実行しないことを考えると、それらの間でsvn：externalsを大量に使用する必要があります。バイナリを操作するのではなく、ソースコードを表示することをお勧めします。

外部を使いすぎると、リポジトリを分岐したり、変更を同期したりすると、複雑でエラーが発生しやすくなる可能性があるため、チームはこのソリューションをまったく信頼していませんでした。

そこで、チームメンバーは、これがより良い解決策になると私たち全員が考える何かを提案しました。すべてのプロジェクトを同じトランクに配置することです。

最初は、このアプローチにいくつかの問題があることを認識しましたが、全体として、これらの問題は、おそらく私たちが経験したことのない架空の状況に基づいていることに同意します。

このソリューションで発生する可能性のある深刻な問題がありますか？

4

4 に答える 4

4

私たちはこれを当社で行っており、多くの成功を収めています。

3つのトップレベルディレクトリがあります。

  • タグ
  • 枝
  • トランク

そして、それらのサブディレクトリとして各プロジェクトがあります。

ただし、プロジェクトレベルで分岐し、svn：externalsを使用します。ただし、ソースツリーが小さい場合は、トランクレベルで分岐し、svn：extenralsを使用しません。

すべてのプロジェクトのトランクを同じ場所に配置できるのは素晴らしいことです。あなたはそれをバックアップすることができます、あなたはそれをすべてチェックすることができます、そしてあなたはすべての最新のものを一緒に持っています。すべてのブランチの単一の場所も、すべてのタグの単一の場所も失われることはありません。これらはすべて/ branchs/projectXおよび/tags/projectXのサブディレクトリにあるためです。

svn：externalsの問題：

プロジェクトが極端に大きくない場合は、毎回トランク全体を分岐して、svn：externalsのすべての問題を回避できます。

svn：externalsの問題は、ブランチを作成するときに、svn：externalsごとにブランチが自動的に作成されないことです。トランクがさらに更新されると、時間の経過とともにすべての古いブランチをコンパイルできなくなるため、これは問題です。もう1つの問題は、svn：externalのいずれかのブランチを修正すると、他のすべてのブランチが壊れることです。

svn externalsのもう1つの問題は、ルートレベルでsvn：logを実行すると、svnexternalsからの変更が表示されないことです。

うまくいけば、上記の問題に対処するためにいつかsvn externalsが修正されるでしょうが、その日までは、svn：externalsは絶対的な悪夢です。

于 2009-04-28T19:39:49.943 に答える
1

あなたが行ったことは、私が会社で設定したことであり、svnbookトピックの「リポジトリ展開の戦略」では「非常に一般的なレイアウト」としても参照されています。

何も悪いことはありません。

于 2009-04-28T19:53:28.897 に答える
1

このソリューションで深刻な問題が発生する可能性はありますか?

  • ソリューションは、すべてを単一のリポジトリに配置できる場合にのみ機能します。

    これは、近い将来、リポジトリ全体が 1 つのディスク (またはストレージ プール) に収まる必要があることを意味します。同様の考慮事項は、ネットワークやディスク I/O 帯域幅などの他のサーバー リソースにも当てはまります。

    後でリポジトリを分割するには、セットアップ全体を大幅にオーバーホールする必要があり、古いバージョンを再構築またはブランチする必要があるときに頭痛の種になる可能性があります。

  • ソリューションは、ユーザーごとに読み取り/書き込み権限を制限する必要がない場合にのみ機能します

    projectA に読み書き権限を与える必要がある場合、実際には /trunk/projectA、/branch1/projectA、/branch2/projectA などに権限を与える必要があります。

    分岐は、多くのパーミッションの微調整を必要とする重いプロセスになります。フィーチャー ブランチに別れを告げましょう。

于 2009-04-28T23:52:46.730 に答える
1

「すべてのプロジェクトを同じトランクに入れる」には：

私の経験では、これは良い考えではありません。各プロジェクトには独自の履歴と変更があり、多くの場合、プロジェクトは異なる開発者によって維持されている/維持されるためです。これは競合につながる可能性があります-たとえあなたが述べたとしても、現在プロジェクトが大きく干渉している.

では、プロジェクト (トランク) を自動的にチェックアウトできる同じコード ベースとビルド スクリプトを確保するために、すべてのプロジェクトに共通のタグ (名前としてマイルストーンを使用) を使用してみませんか? それはより多くの作業ですが、OOP (カプセル化) での通常のように、プロジェクトを個別の SVN ディレクトリに分割することもお勧めします。

しかし: たくさんの小さなライブラリとアプリを同じトランクの下の共通ディレクトリに集めることは問題ありません (以下の私の例の「アプリ」と「ツール」を参照してください) - おそらく「小さなプロジェクト」は共有/大きなトランクにとどまることができます.

例として、SVNのディレクトリ構造を次に示します。

/projects/
/projects/CustomerA/
/projects/CustomerA/ProjectX/
/projects/CustomerA/ProjectX/trunk/
/projects/CustomerA/ProjectX/tags/
/projects/CustomerA/ProjectX/branches/
/thirdparty/
/thirdparty/ExtLibY/
/thirdparty/ExtLibZ/
/tools/
/tools/trunk/
/tools/tags/
/tools/branches/
/apps/
/apps/trunk/
/apps/tags/
/apps/branches/

したがって、外部のものはすべて / thirdparty/ に保存され、すべての内部 (プロジェクト、ツール、アプリ) にはサブディレクトリがあります。

/trunk/
/tags/    
/branches/

...Subversion の本と前の投稿でアドバイスされているように。

一見、少し手間がかかるように見えても、特にコード ベースが大きくなった場合は、その価値があります。

チャオ、クリス

于 2009-04-28T20:45:41.610 に答える