SubversionでVisual Studioプロジェクト用にリポジトリを構築する最善の方法は?

svn
SubversionでVisual Studioプロジェクト用にリポジトリを構築する最善の方法は?

私は多くのアプリケーションに共通のC# `.dll`プロジェクトをいくつか持っています。 現在、私は一つの大きなリポジトリを持っています。 各DLLをリポジトリ内の個別のプロジェクトとして格納し、すべてのアプリケーションプロジェクトを同じリポジトリ内のプロジェクトとして格納します。

私は最近ソース管理のためにSubversionに切り替えました、そして、私はリポジトリを構築するのに良い仕事をしなかったことを恐れます。 他の人がしていることを聞きたいです。

  12  0


ベストアンサー

Subversionリポジトリは通常、次のように細分されます。

枝/タグ/トランク/

すべてのDLLプロジェクトとアプリケーションプロジェクトを* trunk に配置してから、必要に応じてそれらすべてに branch tags *を使用することもできます。

branch / tags / trunk / project1 / project2 /

あるいは、ルート内に各プロジェクト用のフォルダーを作成してから、その中に共通のブランチ、タグ、およびトランクフォルダーを配置することもできます。

project1 / branch / tags / trunk /

project2 / branch / tags / trunk /

この慣例は単なる慣例であり、SVNの中ではこれを厳密にこのようにすることを要求するものではない(または実際に促進している)ものは何もないことに注意してください。 しかし、誰もがそれに慣れています。 それで、あなたは人々が一緒に行くのを好むことをしているでしょう。

さらに詳しく述べると、トランク*はあなたの主な開発が行われる場所です。 特定のリビジョンをマークしたいとき(例: (リリース版)、次にプロジェクトをtagsディレクトリに svn * コピー*します。 また、劇的なことや長引いたことをしたいときや、 trunk の進歩を妨げたくないときは、単に branch *ディレクトリにコードをコピーしてください。 後で、あなたの*ブランチ*を*トランク*にマージすることができます。

現在のSubverionリポジトリの間違いを訂正したい場合は、* svn * * move *を使用してそれらを移動してください。 CVSの削除および追加プロセスとは異なり、moveは新しい場所のバージョン履歴を保持します。

9


branch / trunk / tagリポジトリ構造を使うことはかなり標準的ですが、私があなたを正しく理解しているならば、あなたの問題はあなたが複数のプロジェクトに渡って使われる共通のdllプロジェクトのセットを持っていることです。 これは間違いなく管理が面倒になることがあります。

したがって、ここでの典型的なシナリオは、すべてのアプリケーションに共通のコードを持つCommon.Helpersというクラスライブラリがあることです。

Common.Helpersを参照する必要があるStackOverflow.Webという新しいアプリケーションを始めているとしましょう。

通常は、新しいソリューションファイルを作成し、Stackoverflow.Webという新しいプロジェクトを追加し、既存のCommon.Helpersプロジェクトを追加してから、新しいStackoverflow.Webプロジェクトから参照します。

私が普段やろうとしていることは、Common.Helpersプロジェクト用のリポジトリを作成し、それをSubversionで 外部として参照することです。 そうすれば、コードを単一の場所でソース管理下に置くことができますが、それでも複数のプロジェクトで別々に使用することができます。

5


サブプロジェクトを異なるバージョン(コントロール、Webパーツ、電気ショック療法など)でリリースできる場合は、次のように構造を構築するのが理にかなっています。

ソリューション +プロジェクト1

_
* ブランチ
* Tags
* トランク
_

プロジェクト2

_
* ブランチ
* Tags
* トランク
_

これにより、各プロジェクトリリースを個別に管理できます。

それ以外の場合、最も一般的な構造は次のとおりです。

_
* ブランチ
* Tags
* トランク
* ドキュメント(オプション)
_

0


開発者(または再構築されたdevbox)がSVNからチェックアウトして(必要なすべてのアセンブリを相対パスで)構築しやすいように、すべてをリポジトリに格納します。 別々にする必要がある複数のプロジェクトがある場合は、これによって共有コンポーネントのチームが高品質のアセンブリを提供することも促進されます。 これは、共有されたアセンブリがダウンストリームプロジェクトで更新される生産メンタリティへの通常のリリースに続く可能性があります。 これは非常に自然な ソフトウェアバリューチェーンで、わずかなディスク容量を犠牲にしたものです。

JP Boodhooは、自動ビルド、VSフォルダ構造、そして開発者の迅速な立ち上げをテーマにした 素晴らしいシリーズを公開しています。

0


答えてくれた皆さんに感謝します。 lomaxx、私は午前中に外部機能の使い方を調べてみましたが、これがその方法です。 私はそれを知りませんでした、おそらくそれが亀では正確に目立たないからです。

0


Subversion 1.5のマージ追跡を複数のプロジェクトで同時に使用したい場合は、外観のない単一のツリーを使用してください。

追跡されたマージは(コミットと同じように)常にディレクトリとその子に対するものです。

アトミックコミットにも同じ規則が適用されます。 (単一の作業コピー内でのみ安定して動作します。 それはある特定の他のケースではうまくいくかもしれませんが、その動作は保証されていません

0


タイトルとURLをコピーしました