27

IntelliJ の .IPR および .IWS ファイルをソース管理に保持しますが、プロジェクトで作業を行わなくても、開くだけで IntelliJ によって変更され続けます。

私たちは何を間違っていますか？

4

4 に答える 4

42

「私たちは IntelliJ .IPR および .IWS ファイルをソース管理に保持していますが、プロジェクトで作業が行われていなくても、それらを開くだけで IntelliJ によって変更され続けています。」

.IWS ファイルは間違いなく開発者ごとのファイルであるため、ソース管理下に置くべきではありません。

最近のプロジェクトの .IPR ファイルに関しては、まず、.Net プロジェクトと VS.Net .SLN ファイルの場合と同様に、このファイルを概念的にバージョンアップしようとしました。私たちの目標は、IDE やローカル データベースなどの依存ソフトウェアのインストールにかかる時間を含めて、15 分以内にクリーンな PC で開発者を稼働させることでした。最終的に、以下のようにローカル構成を微調整する時間に近づきました。

問題は、.IPR ファイルが .sln ファイルよりも多くの設定を保存することです。たとえば、個々のプラグインの設定です。したがって、上書きの主な原因は、プラグイン構成が異なる開発者が IPR ファイルを開くと、プラグインのデフォルト設定がファイルに書き込まれることです。開発者は特定のプラグイン スーパー セット (最小構成のみ) に制限する必要はないと感じました。

この問題を (完全に解決したわけではありませんが) 軽減した方法は、.idea フォルダー形式に切り替えることでした。これにより、.IPR ファイルのコンテンツが取得され、多くのノードが .idea サブフォルダー内の個々のファイルとフォルダーに分割されます。ここから、頻繁に書き込まれるファイルの多くをソース管理から除外することができました。除外したファイルの一部は次のとおりです。

  • ワークスペース.xml
  • dataSources.xml
  • sqlDataSources.xml
  • dynamic.xml

IntelliJ に残しておきたいいくつかのファイルは次のとおりです (ただし、責任は Jetbrains だけでなく、プラグイン開発者にもある可能性があります)。

  • projectCodeStyle.xml (これにより、プロジェクトで一貫したコード形式を取得できます。これも、開発者のローカル プラグイン ミックスに基づいて上書きできます)。
  • runConfigurations フォルダーの下の任意のファイル。多くのファセットを含む複雑なアプリがある場合は特に、実行構成の構成に時間がかかる可能性があります。IDE を開くかビルドするだけで変更される最も一般的な愚かなことは、RunnerSettings の下の「DEBUG_PORT」オプションです。私の意見では、動的に割り当てられている場合、「動的」の値を持たないのはなぜですか?
  • その他.xml。このファイルには、プラグイン構成も含まれています。一部の設定は共有すると便利に見えますが、他の設定はより個人的な構成に見えます。たとえば、IvyIDEA プラグインは、ivy 構成ファイルへの絶対パスを設定します。
  • モジュールファイル。これらはほとんどそのまま残されていますが、不必要な上書きの例としては、IvyIDEA プラグインがローカルの ivy-cache の場所の詳細をこのファイルに入れていることがあります。しかし、これはプラグインのせいであり、Jetbrains の問題ではありません。

お役に立てれば。

キリスト教徒。

于 2009-06-23T07:35:23.227 に答える
4

何が変更されているのかを正確に知らなければ、これに自信を持って答えるのは少し難しいですが、私はこう言います：

  • IWSファイルには、開発者のIDEがこのプロジェクトにどのように配置されているかを説明する情報が含まれています（最近の変更履歴、各エディターウィンドウの現在の状態、表示されているドッキング可能なウィンドウ、折りたたまれているウィンドウなど）。各開発者が自分のワークスペースを好きなように配置できるようにする必要があることを考えると、これらはソース管理下にあるべきではありません。

  • IPRファイルは、プロジェクトコードの構造を記述します。これは、プロジェクトの一部であるモジュール、使用するbuild.xmlファイル、コードをコンパイルするライブラリの場所などを意味します。これはソース制御で行うことができますが、これらの設定を開発者のプロジェクトのコピーごとに変更できるようにすると、大雑把になります。

IPRファイル内にlibraryTableコンポーネントがある場合：

ほぼ確実に起こっていることは、各開発者が共有ライブラリ（JAR）（コードのビルドに必要）をローカルマシンのさまざまな場所に保持していることです。変更をコミットすると、ライブラリの場所がIPRファイルに書き込まれます。これを行うと、プロジェクトを更新したときに、IPRのコピーとあなたのコピーがこれらのJARの場所で競合することになります。

この問題を回避するには、JARファイルを共有の場所（マップされたネットワークドライブなど）に配置し、すべての開発者がこれらのファイルを同じ場所にダウンロードするようにします（プロジェクトルートの下のlibサブフォルダーが適切に機能します）。欠点は、プロジェクト間で同じJARの複数のコピーが作成されることです（各プロジェクトは独自のlibフォルダーを参照します）が、利点は、すべての開発者が同じプロジェクト構造を使用しているため、IPRの更新がはるかにうまくいくはずです。

さもないと：

IntelliJがマージしようとしているものを確認してください（更新するときに、ファイルを手動でマージするか、相違点を表示するかを選択できます。それ以外の場合は、お気に入りの差分ツールを使用します）。マージの競合がどのように見えるかについてもう少し情報を使用して質問を更新できれば、ホイールがどこから外れているのかを簡単に確認できる可能性があります。

于 2009-06-22T08:17:07.550 に答える
1

ソース管理 (.deleteme) にチェックインされたものに拡張子を追加します。その後、新しい人がプロジェクトをチェックアウトし、拡張機能を変更して作業を開始できます。構成を変更すると、チェックインされたファイルが更新されます。

于 2009-09-23T00:21:46.923 に答える
0

解決策の 1 つは、IntelliJ プロジェクトをソース管理下に置かないことです。これは、再作成が容易であることを意味します。

無視すべきファイルについて Subversion に伝えることができます。IntelliJ ファイルをそのリストに追加します。

「...プロジェクトで作業が行われていなくても....」 - これは、プロジェクトで有用な作業を行わずに IntelliJ を頻繁に開くことを示唆しています。多分それは本当の問題です。チェックインする価値のある何かを実行せずに IDE を開く理由がわかりません。また、リビジョン番号の上昇のコストはいくらですか? 私の意見では、小さいです。

だから今、私は考えを変えました。IntelliJ プロジェクト ファイルをチェックインします。リビジョン番号の上昇を心配する必要はありません。彼らはあなたに多くの費用をかけていません。

于 2009-06-16T09:53:55.280 に答える