現在、ソース管理には SVN を使用しています。追加機能と開発環境での統合のため、TFS 2012 に移行したいと考えています。
asp.net で構築された多数のポータルが実行されています。ポータル内では、多くの標準コンポーネントを使用しています。現在、すべてのポータルが同じコード ベースを使用しています。これは、共有コードベースで何かを変更するたびに (ポータルが公開されるたびに) 自動的に配布されることを意味します。私たちはこの作業方法に非常に慣れており、他のポータルでコードを壊すリスクがあることを知っています。ただし、他のすべてのポータルで変更を公開するには、かなりの時間がかかります。これを行うには、SVN でエクスターナルを使用します。
私は本当にこの機能を維持したいと思っています。だから私の質問は、SVN で外部のようなシステムを作成する方法があるか、またはこの機能を置き換えるのと同じくらい効率的に機能する本当に良い方法があるかということです。
Visual Studio Team Foundation Server Branching and Merging Guideには、いくつかの提案があります。
"Everything" パッケージをダウンロードして "All Guides" zip を調べ、"Advanced Version Control Guide" を読んだ場合。
ページ 5 ～ 19 (バージョン 2.1) では、共有リソースの管理について説明しています。そこには多くの情報があり、スタック オーバーフロー用にすべてを要約すると、おそらくレンジャーの不当な扱いになるでしょう。
結論: TFS には "svn:externals" に相当するものはありません。
コードの共有は悪いことであり、コードの重複につながりますが、コードの再利用にはつながりません。代わりに、コンパイルされたコードに依存してください。
ソースファイルではなく、共有ライブラリの「出力」のみに依存する必要があります。シナリオに関しては、製品/ソリューション間でソース ファイルを共有することが推奨されるシナリオは思い浮かびません。
その理由は、物事が非常に急速に複雑になり、扱いにくくなる可能性があるためです。1 つ以上の依存関係を共有ライブラリに移動し、それらすべてが同じコードに変更され、それらが交互に壊れるとしたらどうなるでしょうか。これを回避する唯一の方法は、共通コードを他のプロジェクトに分岐することです。これにより、長期的には決して処理されないレベルの複雑さと統合が追加され、同じコード ベースの 3 つ以上のバージョンが存在することになります。時間。
すべきことは、出力を生成するように変更およびビルドされる単一のコア コンポーネントを用意することです。この出力は、これらの変更に依存するかどうかに関係なく、必要に応じて他のプロジェクトにプルできます。これにより、破損が少なくなり、アーキテクチャが改善され、技術的負債が少なくなります。
社内サーバーでホストされているいずれかを使用して NuGet を方程式に導入し、共通コンポーネントを公開して、新しいバージョンが利用可能になったときに各コンシューマーに通知することもできます。