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

Question

除了明显的源代码之外，哪些 Eclipse 文件适合置于源代码控制之下？

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

.元数据/*
项目目录/.project
项目目录/.classpath
项目目录/.settings/*

如果它依赖于其中任何一个，请解释您的指导方针。

Answer 1

考虑：

.classpath
.project
.launch

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

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

Answer 2

CDT 配置文件对源代码控制不友好是毫无价值的。 .cproject 文件经常更改并导致冲突，请参阅 Sharing cdt-project files in repository always causes conflicts。

Answer 3

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

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

它们位于

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

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

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

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

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

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

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

为此，您只想在 .classpath 中使用 相对路径，使用 linked resources。

注意：最好project-dir 指的是“外部”项目目录，而不是在 Eclipse 工作区下创建的目录。这样一来，这两个概念（eclipse 工作区与 SCM 工作区）就清晰地分开了。

---

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

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

Answer 4

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

如果您在一个团队中工作，那么我认为以下是非常好的受版本控制的候选者：

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

Answer 5

.classpath 文件绝对是签入 scm 的理想选择，因为手动设置它可能需要大量工作，并且对于新开发人员进入项目来说会很困难。确实它可以从其他来源生成，在这种情况下，您将签入其他来源。

至于.settings，取决于设置。这是一个灰色区域，但有些设置几乎是强制性的，并且可以很方便地签出项目，将其导入 Eclipse 并设置好一切，一切顺利。

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

Answer 6

一些项目，比如使用 Maven 的项目，喜欢基于 POM 生成 .project 文件。

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

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

Answer 7

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

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

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

Answer 8

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