プロジェクト構成ファイルのSubversion管理

Question

環境ごとに複数の同時バージョンがある単一の構成ファイルを必要とするプロジェクトの管理に、Subversion（SVN）を使用する場合のベストプラクティスは何ですか。

I.e.

• プロジェクトABCは、わずかに変更された構成ファイルを除き、同じコードを使用する3つの異なる環境で使用されます。 AND
• プロジェクトABCは、開発者ごとに若干変更された構成ファイルを使用して複数の開発者によって開発されています。

私は、構成ファイルテンプレートとsvn：ignoreを使用できることを知っていますが、誰かがこの方法や他の適切な選択肢のベストプラクティスを記述できるかどうか疑問に思っていました。

ありがとうございます！

M.

Answer 1

これは「ベストプラクティス」である場合、私は知りませんが、これは私がこれを処理し、それは非常にうまく機能する方法です。私はいくつかのアプリを持っていて、彼らはそれぞれプロダクション、ステージング、および開発環境のための別々の設定ファイルを持っています。 configsの名前はweb.config、stage.config、dev.configです。 3つはバージョン管理下に置かれます。アプリケーションは、web.configを使用して設定を取得し、設定を取得します。クルーズコントロールによって呼び出されるNANTビルドスクリプトと配備スクリプトの一部として、配備先の環境に応じて、適切なconfigの名前がweb.configに変更され、配備されます。

これが役に立ちます。

Answer 2

ソース管理に複数のファイルを保存するのは難しい場合があります。私たちはシステム環境変数を読み込み、一致する設定ファイルを読み込んでから共有設定ファイルを変更する自家製の設定ツールを使用します。私はそれが素晴らしい解決策だとは言えませんが、うまくいきます。

Answer 3

多くの成功したプロジェクトでは、システムまたは開発者固有の設定ファイルをバージョンアップしていないだけです。場合によっては、データベースのアクセス情報、またはいくつかの重要なパスなどです。できるだけ絞ってください。その情報をバージョン管理していないということについて悪くはありません。これは、複数のプロジェクトで2〜5人の開発者の間で行われており、現実世界のプロジェクトで混乱、問題、または議論を引き起こしたことはありません。

Answer 4

私の意見では、すべてのconfiguartionファイルをバージョン管理下に置いておくのは無駄です。私のプロジェクトの1つでは、（同じテンプレートの）複数のプラットフォーム用にcmakeで作成された設定ファイルがありました。私たちのチームのすべての開発者は、必要なconfigsを作成するためのカスタマイズされた追加スクリプトを持っていました。