プロジェクトが2つの異なる.NETソリューションの一部である必要がある場合のSVNの処理方法は？

Question

私はいくつかのプロジェクトを含む.Net C＃ソリューション（A）に取り組んでいます。 このソリューションは、SVNを介してソース管理されています。

ここで、ソリューションAのプロジェクトの1つを含む新しいソリューション（B）の作業を開始したいと思います。このソリューションBは、SVNでもソース管理する必要があります。

最も明白な解決策は、解決策Bを作成し、関係するプロジェクトだけを含めることです。 これを行うと、関連するプロジェクトは2つの異なるSVNフォルダの一部になります。私は、これがその後の問題のトンを作成すると思いますか？

ソリューションは、ソリューションをSVNフォルダから削除し、プロジェクト用の専用のSVNフォルダを作成することもできます。欠点は、ソリューションA（またはB）を更新するときに、ソリューションA（またはB）とプロジェクトSVNフォルダの変更をコミットする必要があることです。しかし、おそらく以前のソリューションよりも優れていますか？

その他のオプションはありますか？この場合のベストプラクティスは何ですか？

あなたの知識のためのthx。

Answer 1

ベストプラクティスは、必要に応じて異なります。

へのあなたの最初のアイデア：

溶液Bを作成し、ちょうど心配プロジェクト

は、SVN側ですべての問題を作成しません含まれます：SVNは、AとBがAを共有していることを知ることができませんサブプロジェクト（今からSS）。 2つのSSを別々のプロジェクトとして保守したい場合、それを行うことができますが、何の欠点もありません。 逆に、 "同じプロジェクト"としてSSを管理する必要がある場合は、ローカルコピーで手動でSSを更新し、AまたはBで作業するときにSSを変更するたびにSVNにコミットする必要があります。

あなたは「同じプロジェクト」としてSSを管理する必要がある場合は最善の解決策は、2番目のいずれかです。

ソリューションA SVNフォルダからプロジェクトを削除し、プロジェクト

専用のSVNのフォルダを作成します

この場合、SSコードは実際には同じで実際に共有されます。

希望...チェックアウト、アップデートを手伝って、あなたはその後、より快適にするために、いくつかのバッチスクリプトを作成することができますコミットするには、この

Answer 2

私はnuGetパッケージを介して共有プロジェクト（複数可）をパッケージ化する検討したいことができます。

このようにして、3つのサブバージョンフォルダ（a、b、共有）を使用できます。 共有は、必要に応じて（ローカル）ネットワークフォルダに公開するNuGetパッケージに出力できる（独自のテストなどを含む）ソリューションです。

ソリューションAとBは、リビジョン管理を含むパッケージ化されたライブラリを参照します。