.dll
多くのアプリケーションに共通するC#プロジェクトがいくつかあります。現在、1つの大きなリポジトリがあります。各DLLをリポジトリ内の個別のプロジェクトとして保存し、すべてのアプリケーションプロジェクトを同じリポジトリ内のプロジェクトとして保存しています。
私は最近、ソース管理のためにSubversionに切り替えましたが、リポジトリをうまく構築できなかったのではないかと心配しています。他の人がしていることを聞きたいです。
.dll
多くのアプリケーションに共通するC#プロジェクトがいくつかあります。現在、1つの大きなリポジトリがあります。各DLLをリポジトリ内の個別のプロジェクトとして保存し、すべてのアプリケーションプロジェクトを同じリポジトリ内のプロジェクトとして保存しています。
私は最近、ソース管理のためにSubversionに切り替えましたが、リポジトリをうまく構築できなかったのではないかと心配しています。他の人がしていることを聞きたいです。
Subversionリポジトリは、通常、次のように細分化されます。
branch/
tags/
trunk/
すべてのDLLおよびアプリケーションプロジェクトをトランクに配置し、必要に応じてそれらすべてにブランチとタグを使用します。
branch/
tags/
trunk/
project1/
project2/
または、ルートにプロジェクトごとにフォルダーを作成し、その中に共通のブランチ、タグ、トランクフォルダーを配置することもできます。
project1/
branch/
tags/
trunk/
project2/
branch/
tags/
trunk/
この慣行は単なる慣例であり、SVNではこれを正確にこのようにする必要はありません(または実際に促進するものはありません)。しかし、誰もがそれに慣れています。だから、あなたは人々に一緒に行くのを好むでしょう。
さらに詳しく説明すると、トランクは主な開発が行われる場所です。特定のリビジョン(リリースバージョンなど)をマークする場合は、プロジェクトをタグディレクトリにsvn コピーするだけです。また、劇的なことや長時間のことをしたいが、トランクの進行を妨げたくない場合は、コードをブランチディレクトリにコピーするだけです。後で、アクションの準備ができたら、ブランチをトランクにマージして戻すことができます。
現在のSubverionリポジトリの事故を修正したい場合は、svnmoveを使用し てそれらを再配置します。CVSの削除および追加プロセスとは異なり、moveは新しい場所のバージョン履歴を保持します。
ブランチ/トランク/タグリポジトリ構造を使用することはかなり標準的ですが、私があなたを正しく理解している場合、あなたの問題は、複数のプロジェクトで使用される共通のdllプロジェクトのセットがあることです。これは間違いなく管理が難しい場合があります。
したがって、ここでの典型的なシナリオは、すべてのアプリケーションに共通のコードを持つCommon.Helpersというクラスライブラリがあることです。
Common.Helpersを参照する必要があるStackOverflow.Webという新しいアプリケーションを起動しているとしましょう。
通常は、新しいソリューションファイルを作成し、Stackoverflow.Webという新しいプロジェクトを追加し、既存のCommon.Helpersプロジェクトを追加して、新しいStackoverflow.Webプロジェクトから参照します。
私が通常試みているのは、Common.Helpersプロジェクトのリポジトリを作成し、subversionでそれを外部として参照することです。そうすれば、コードを1つの場所でソース管理下に置くことができますが、それでも複数のプロジェクトで別々に使用できます。
サブプロジェクトをさまざまなバージョン(コントロール、Webパーツなど)でリリースできる場合は、次のように構造を構築するのが理にかなっています。
ソリューション
プロジェクト1
- ブランチ
- タグ
- トランク
プロジェクト2
- ブランチ
- タグ
- トランク
このようにして、各プロジェクトリリースを個別に管理できます。
それ以外の場合、最も一般的な構造は次のとおりです。
- ブランチ
- タグ
- トランク
- ドキュメント(オプション)
開発者(または再構築された開発ボックス)がSVNからチェックアウトしてから、ビルドを実行しやすいように(必要なすべてのアセンブリを相対パスに入れて)、すべてをリポジトリに保存します。別々にする必要のある複数のプロジェクトがある場合、これにより、共有コンポーネントのチームが高品質のアセンブリを提供することも奨励されます。これは、共有アセンブリがダウンストリームプロジェクトで更新される、本番環境への通常のリリースに続く可能性があります。これは非常に自然なソフトウェアバリューチェーンですが、ディスク容量が少し犠牲になります。
JP Boodhooには、自動ビルド、VSフォルダー構造、および開発者の迅速な立ち上げと実行に関するすばらしいシリーズがあります。
同時に複数のプロジェクトで Subversion 1.5 のマージ追跡を使用したい場合は、外部のない単一のツリーを使用する必要があります。
追跡マージは (コミットと同様に) 常にディレクトリとその子に対して行われます。
同じルールがアトミック コミットにも適用されます。(単一の作業コピー内でのみ安定して動作します。他の特定のケースでは動作する可能性がありますが、その動作は保証されていません)
答えてくれたみんなに感謝します。lomaxx、私は午前中に外部機能の使用を検討しましたが、これが進むべき道のようです. おそらくTortoiseではそれほど目立たないため、私はそれを知りませんでした.