0

いくつかのバックグラウンドから始めるために、私は ASP.NET アプリケーションを開発する小さなチームのメンバーです。私たちに加えて、他に 2 つのチームが取り組んでおり、すべて異なる国から来ています。ソース コードは共有 SVN サーバーでホストされていますが、中央のテスト環境はありません。各開発者は自分のマシンでアプリを実行し、データ サービスはチームごとにセットアップされます。

残念ながら、私たちの SVN ワークフローにはいくつかのギャップがあります。

これは主に、各開発者とチームが、ディスク ディレクトリ構造と構成 (IIS とアプリ自体の両方) に関してわずかに異なる環境を持っているためです。したがって、本質的にはまったく競合しない構成ファイルや他の場所での競合 - ランタイム構成 (XML) および *.suo での競合。

チェックアウト、アプリのセットアップ、および更新をできるだけ簡単に行うことが目的である場合、これをどのように処理する必要がありますか?

1 つのオプションは明らかにマスター コピーです。もう 1 つは、開発者環境の統一を確立し、それを維持することです。しかし、3 番目の選択肢はどうでしょうか。

4

4 に答える 4

2

やるべきことの 1 つは、.suoファイルを SVN に入れないことです。そうする理由はありません。

于 2012-04-13T07:58:44.140 に答える
1

svn の *.suo および *.user ファイルを無視します。簡単です。その後、subversion に 2 種類の構成ファイルを作成します。開発とサーバー、使用している場合はテストも追加します。以下の例を参照してください。

ConnectionStringDevelopment.config
ConnectionStringServer.config

AppSettingsDevelopment.config
AppSettingsServer.config

サーバー ファイルには、サーバー情報が含まれます。開発ファイルは svn に含まれておらず、そこでは無視されます。すべての新しい開発者は、サーバー ファイルをコピーし、環境に応じて変更を加えることから始めます。

次の例のサイトを見て ください http://code.google.com/p/karkas/source/browse/trunk/Karkas.Ornek/WebSite/web.config

次の行は興味があります。

<appSettings configSource="appSettingsDevelopment.config"/>
<connectionStrings configSource="ConnectionStringsDevelopment.config" />

ConfigSourceは web.config のほぼすべての場所で使用できるため、すべての構成をすべての開発者に変更できます。次の命名規則のみを使用してください。Subversion では *Development.config を無視します。この方法では、開発者の構成が Subversion に追加されることはありません。

于 2012-04-22T19:23:21.957 に答える
1

IIS 構成については、引数はありません。ビルド チーム全体で環境が統一されている必要があります。

app.config ファイルなどについては、プロジェクトのルートにある別の「cfg」ディレクトリに保存し、ビルド前のイベントを使用して、プロジェクトや環境に応じて必要な関連イベントをコピーする傾向があります。取りかかっている。

ユーザー固有の構成を出力ディレクトリにコピーする別のビルド タスクを作成できます。ルート プロジェクトに「user.config など」という名前の新しいディレクトリを追加し、空のままにします。次に、プロジェクト ビルドを構成してエントリをチェックし、それらを出力ディレクトリにコピーします。これは簡単に実行でき、各開発者は次のことができます。マスター コピーに影響を与えずに独自の構成を持っている. ユーザー固有の構成をコミットしないように、そのフォルダーに無視パターンがあることを確認してください. ソース コード リポジトリへの svnadmin アクセス権を持っている場合は、フックを設定して防止することができますそれは今までに起こったことから。

また、.suo、.user、_Resharper、または関連すると思われるその他の拡張子について、ルート ディレクトリに無視パターンを (再帰的に) 設定します。まさにこのトピックに関する質問がいくつかあります。

最も一般的な SVN 無視パターン?

于 2012-04-18T12:09:09.083 に答える
0

これは完璧な解決策ではありませんが(これらの特別なファイルがあまりない場合にのみ使用する必要があります)、私が行うことは、それぞれの場合に偽のファイルを追加し、実際のファイルをローカルに切り替えることです。詳細:問題を引き起こすファイルfooがあります。また、foo_1とfoo_2を作成してから、ローカルでfooをfoo_1に切り替えます(tortoisesvnを使用しているため、これを行うためのコマンドラインを実際に提供することはできません)。次に、自分のマシンでfooに取り組んでいますが、実際にはfoo_1にコミットしています。その後、他のパーティはfoo_2に切り替えることができます...

(これは基本的に、あなたが自分で提案したマスターファイルアプローチの変形であることを認めます。しかし、これらのファイルに実際の変更があまりない場合、これにより、少なくとも考えなければならない競合の数が減ります)

于 2012-04-13T10:15:28.193 に答える