web-dev-qa-db-ja.com

バージョン管理下にあるEclipseファイルはどれですか？

ソースはもちろん、ソース管理下に置くのに適切なEclipseファイルはどれですか？

私のプロジェクトでは、具体的には、次のことを考えています：

.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*

依存するこれらのいずれかがある場合、ガイドラインを説明してください。

eclipseversion-controlsvn
239
sblundy

メタデータはソース管理で管理しないでください。ほとんどの場合、yourワークスペースに関連するデータが含まれます。

唯一の例外は、.launch XMLファイル（ランチャー定義）です。

それらは

[Eclipse-workspace]\.metadata\.plugins\org.Eclipse.debug.core\.launches

また、プロジェクトディレクトリにコピーする必要があります。プロジェクトが更新されると、それらの構成が[構成の実行]ダイアログに表示されます。

そのようにして、これらの起動パラメーターファイルもSCMで管理できます。

（警告：実行関連付けられたリソースが削除されたときに構成を削除する]オプションのチェックを外す inRun/Launching/Launch Configuration設定パネル：プロジェクトをソフトで削除してインポートし直す-Eclipseメタデータの再初期化を強制するのが一般的ですが、このオプションをチェックすると、プロジェクトが削除されます詳細な起動パラメーター！）

project-dir/.project
project-dir/.classpath
project-dir/.settings/*

sCMにある必要があります（特に Eclipseドキュメント に従って.projectおよび.classpath）。

目標は、誰でも自分のSCMワークスペースをチェックアウト/更新し、EclipseプロジェクトをEclipseワークスペースにインポートできることです。

そのためには、リンクされたリソースを使用して、.- classpathで相対パスのみを使用します。

注：project-dirは、Eclipseワークスペースの下に作成されたディレクトリではなく、「外部」プロジェクトディレクトリを参照する方が適切です。このように、2つの概念（EclipseワークスペースとSCMワークスペース）は明確に分離されています。

ipsquiggle がコメントに記載されており、 古い回答で をほのめかしているように、実際に起動設定を共有ファイルとして直接保存できます。プロジェクトディレクトリ内。すべての起動設定は、他のプロジェクトファイルと同様にバージョン管理できます。

（ブログの投稿から ヒント：起動設定の作成と共有 KDから）

alt text

173
VonC

現在、.projectおよび.cprojectファイルがソース管理下にあるプロジェクトに取り組んでいます。アイデアは、ライブラリパスとリンクディレクティブに関連する設定がチーム全体に伝播することでした。

実際にはうまく機能していませんでした。ほとんどの場合、マージは競合状態に戻り、Eclipseの外部で競合を解消する必要があります。その後、変更を有効にするためにプロジェクトを閉じて再開しました。

ソース管理に保管することはお勧めしません。

17
pdemarest

CDT 設定ファイルがソース管理に適していないことは何の価値もありません。非常に頻繁に変更され、競合を引き起こす.cprojectファイルについて報告されているバグがあります。リポジトリ内のcdt-projectファイルを共有すると常に競合が発生します。

13
Diaa Sami

Mavenを使用するプロジェクトなど、POMに基づいて.projectファイルを生成するプロジェクトがあります。

そうは言っても、それ以外は-.metadataをソース管理に含めるべきではありません。プロジェクトでは、標準の管理方法などに基づいて、projectdir/.settingsが実行するかどうかを判断する必要があります。開発者が標準に基づいて環境をセットアップすることを正直に信頼でき、プロジェクトに特別なものをカスタマイズする必要がない場合は、開発者を配置する必要はありません。 。これにより、開発者はデフォルト設定を前後に変更することなく、同じワークスペースで複数のプロジェクトに取り組むことができます。また、プロジェクトの標準に一致するデフォルト設定をオーバーライドして、設定を非常に明確にします。

難しいのは、すべてが同期していることを確認することです。ただし、ほとんどの場合、プロジェクトからプロジェクトに.settingsファイルをコピーできます。ソース管理で特に必要としないものがある場合は、SCMでサポートされている場合、それらに対してsvn：ignoreを設定するのと同等の操作を行います。

7
John Stoneham

.classpathファイルはscmをチェックインするのに最適な候補です。手作業で設定するのは大変な作業であり、新しい開発者がプロ​​ジェクトに参加するのは困難です。他のソースから生成できるのは事実です。その場合は、他のソースをチェックインします。

.settingsに関しては、設定に依存します。これは灰色の領域ですが、一部の設定はほとんど必須であり、プロジェクトをチェックアウトし、Eclipseにインポートして、すべてをセットアップして準備ができていると便利です。

したがって、プロジェクトでは、CVS.settingsという.settingsフォルダーのコピーを維持し、それを.settingsにコピーするantタスクがあります。 CVSからプロジェクトを取得したら、「eclipsify」antタスクを呼び出して、デフォルト設定を新しい.settingsフォルダーにコピーします。プロジェクトで開発している全員が必要とする設定を構成する場合、それらをCVS.settingsフォルダーにマージし、CVSにコミットします。この方法でSCMに設定を保存することは、意識的なプロセスになります。大きな変更がチェックインされるときに、開発者がこれらの設定を.settingsフォルダーにマージする必要があります。しかし、驚くほどうまく機能するシンプルなシステムです。

6
Stijn de Witt

私はそれらのどれも言わないでしょう。ほとんどの場合、ワークステーションにのみ関連する情報が含まれています（ライブラリとすべてのパスについて考えています）。また、チームの誰かがEclipseを使用していない場合はどうなりますか？

4
agnul

考慮してください：

.classpath
.project
.launch

これらは、プロジェクト相対パスの使用に固執する限り、バージョン管理する必要があります。これにより、他の開発者がプロ​​ジェクトをチェックアウトし、他の開発者が経験したセットアップのすべての苦痛を経験することなくすぐに作業を開始できます。

Eclipse開発者がワークスペース全体をチェックアウトし、すべての適切なプロジェクトを事前に構成できるように、バージョン管理にも.metadataを含めるように誘惑されるかもしれませんが、誰でも作業できるように、多くのユーザー固有の情報が含まれています変更するため、.metadataを含めないことをお勧めします。既存のすべてのEclipseプロジェクトをインポートするだけで、ローカルワークスペースを簡単に構築できます。

2
Alex McCarrier

私は新しい同僚（および私）のEclipseワークスペース設定の構成に多くの時間を費やしました。最終的に私がやったことは、自分の.metadataを新しい開発者のマシンにコピーすることでした。

チームで作業している場合、バージョン管理下に置くべき非常に良い候補は次のとおりだと思います。

  • インストールされたJREとその名前
  • サーバーランタイム環境
  • Javaエディターテンプレート
  • バージョン管理キーボードショートカット
  • プロジェクト固有の設定を提供しないプラグイン設定
  • Maven設定
  • 事前構成されたパースペクティブ
  • ...
1
Reto Höhener