7

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

つまり

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

構成ファイルテンプレートとsvn：ignoreを使用できることは承知していますが、このアプローチのベストプラクティスやその他の適切な代替案を誰かが説明できるかどうか疑問に思っていました。

前もって感謝します！

M。

4

4 に答える 4

3

これが「ベストプラクティス」かどうかはわかりませんが、これが私がこれを処理する方法であり、非常にうまく機能します。私はいくつかのアプリを持っており、それぞれに本番環境、ステージング環境、および開発環境用の個別の構成ファイルがあります。構成には、web.config、stage.config、および dev.config という名前が付けられます。3 つすべてがバージョン管理下に置かれます。アプリは、web.config を想定して使用し、構成設定を取得します。Cruise Control によって呼び出される NANT ビルドおよび展開スクリプトの一部として、展開先の環境に応じて、適切な構成の名前が web.config に変更されて展開されます。

お役に立てれば。

于 2009-09-30T02:14:30.327 に答える
1

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

于 2009-09-30T02:25:00.867 に答える
0

私の意見では、すべての構成ファイルをバージョン管理下に置いても意味がありません。私のプロジェクトの 1 つで、(同じテンプレートから) 複数のプラットフォーム用に cmake で作成された構成ファイルがありました。私たちのチームのすべての開発者は、必要な構成を作成するための独自のカスタマイズされた追加スクリプトを持っていました。

于 2009-09-30T08:34:44.470 に答える
0

何年にもわたって、そして多くのさまざまな成功したプロジェクトで、私はシステムまたは開発者固有の構成ファイルをバージョン管理していません。場合によっては、データベースへのアクセス情報、またはいくつかの重要なパスなどです。できるだけ小さくします。その情報をバージョン管理しないことを気にしないでください。これは、いくつかのプロジェクトで 2 人から 5 人の開発者のすべての数で行われており、実際のプロジェクトで混乱、問題、または議論を引き起こしたことはありません。

于 2009-09-30T07:06:27.647 に答える