哪些Eclipse文件属于版本控制？

Question

哪些Eclipse文件适合置于源代码管理之下，显然除了源代码？

在我的项目中，具体来说，我想知道：

  

.metadata / *
  项目DIR /。工程
  项目DIR /的.classpath
  project-dir / .settings / *

如果有任何相关信息，请解释您的指南。

Answer 1

不应在源代码管理中管理元数据。它们主要包含与您的工作区相关的数据。

唯一的例外是.launch XML文件（启动器定义）。

他们在

中找到

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

并且应将它们复制到项目目录中：刷新项目时，这些配置将显示在“运行配置”对话框中。

这样，那些启动参数文件也可以管理到SCM中。

（警告：在运行 / 启动 / 启动时，取消选中“删除关联资源时删除配置”选项配置首选项面板：通常软删除项目以便再次导入它 - 强制重新初始化eclipse元数据。但是如果选中此选项，将删除详细的启动参数！）< / p>

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

应该在您的SCM中（根据Eclipse documentation，尤其是.project和.classpath。）

目标是任何人都可以签出/更新他/她的SCM工作区并将Eclipse项目导入Eclipse工作区。

为此，您希望使用 linked resources 在.classpath中仅使用相对路径。

注意：如果project-dir引用“外部”项目目录，而不是在eclipse工作区下创建的目录，则更好。这样，两个概念（eclipse工作区与SCM工作区）明显分开。

---

正如ipsquiggle在评论中提及的那样，正如我所提到的in an old answer，您实际上可以将启动配置直接保存为项目目录中的共享文件。然后，所有启动配置都可以像其他项目文件一样进行版本控制。

（来自KD的博文Tip: Creating and Sharing Launch Configurations）

Answer 2

我目前正在开发一个项目，我们在源代码管理下拥有.project和.cproject文件。我们的想法是，与库路径和链接指令相关的设置将在整个团队中传播。

在实践中它没有很好地工作，合并几乎总是回到冲突状态，需要在eclipse之外解除冲突，然后项目关闭并重新打开以使更改生效。

我不建议将它们保存在源代码管理中。

Answer 3

CDT配置文件不是源代码控制友好的。有一个针对.cproject文件的错误提交频繁更改并导致冲突，请参阅 Sharing cdt-project files in repository always causes conflicts 。

Answer 4

有些项目，比如那些使用Maven的项目，喜欢根据POM生成.project文件。

那说，除此之外 - .metadata不应该在源代码控制中。根据您计划管理标准的方式，您的项目必须确定projectdir / .settings是否有效。如果您可以诚实地信任您的开发人员根据标准设置他们的环境，并且您不必为任何项目定制任何特殊的环境，那么您就不需要将它们放入。我，我建议专门配置每个项目。这允许开发人员在同一工作区中处理多个项目的内容，而无需来回更改默认设置，并且它使设置非常明确，覆盖其默认设置以匹配项目的标准。

唯一困难的部分是确保它们保持同步。但在大多数情况下，您可以将.settings文件从项目复制到项目。如果在源代码管理中有任何特别不需要的内容，请执行相应的设置svn：ignore，如果您的SCM支持它。

Answer 5

.classpath文件绝对是检查scm的一个很好的选择，因为手动设置可能需要很多工作，并且新开​​发人员很难进入项目。确实可以从其他来源生成，在这种情况下，您将检查其他来源。

至于.settings，取决于设置。这是一个灰色区域，但是一些设置几乎是强制性的，并且可以方便地检查项目，在Eclipse中导入它并设置好所有东西。

在我们的项目中，我们维护了一个名为CVS.settings的.settings文件夹的副本，我们有一个ant任务将其复制到.settings。从CVS获取项目时，可以调用“eclipsify”ant任务将默认设置复制到新的.settings文件夹。配置项目开发人员所需的设置时，将这些设置合并回CVS.settings文件夹并将其提交给CVS。这样，在SCM中保存设置成为一个有意识的过程。它确实需要开发人员在签入大的更改时不时将这些设置合并到他们的.settings文件夹中。但这是一个非常简单的系统。

Answer 6

我不会说他们。它们很可能包含仅与您的工作站相关的信息（我正在考虑库和所有路径）。如果团队中有人不使用Eclipse，那该怎么办？

Answer 7

考虑：

.classpath
.project
.launch

只要您坚持使用项目相对路径，这些应该在版本控制中。这允许其他开发人员检查项目并立即开始工作，而不必经历其他开发人员所经历的所有设置痛苦。

您可能很想在版本控制中包含.metadata，因此Eclipse开发人员可以检查整个工作区并预先配置所有正确的项目，但它包含许多用户特定的信息，任何人都可以随时使用它，它会改变，所以我建议不要包含.metadata。只需导入所有现有的Eclipse项目，就可以轻松构建本地工作区。

Answer 8

我花了太多时间为新同事（和我自己）配置eclipse工作区设置。我最终做的最终是将我自己的.metadata复制到新的开发者机器上。

如果您正在组建一个团队，那么我认为以下是非常适合保持版本控制的候选人：

• 已安装的JRE及其名称
• 服务器运行时环境
• Java编辑器模板
• 版本控制键盘快捷键
• 不提供项目特定设置的插件设置
• Maven设置
• 预先配置的观点
• ...