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

Question

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

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

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

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

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

Answer 1

不应在源代码管理中管理元数据。他们主要包含相关数据的工作区。唯一的例外是.launchXML文件（启动器定义）。他们被发现[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches并且应将它们复制到项目目录中：刷新项目时，这些配置将显示在“运行配置”对话框中。这样，那些启动参数文件也可以管理到SCM中。（警告：在“ 运行 / 启动 / 启动配置”首选项面板中取消选中“删除关联资源时删除配置”选项：通常软删除项目以便再次将其导入 - 强制重新初始化eclipse元数据。但是这个选项，如果选中，将删除你的详细启动参数！）project-dir/.projectproject-dir/.classpathproject-dir/.settings/*应该在你的供应链管理（尤其是.project和.classpath根据Eclipse文档）。目标是任何人都可以签出/更新他/她的SCM工作区并将Eclipse项目导入Eclipse工作区。为此，您希望使用链接资源仅在.classpath中使用相对路径。注意：如果project-dir引用“外部”项目目录，而不是在eclipse工作区下创建的目录，则更好。这样，两个概念（eclipse工作区与SCM工作区）明显分开。正如ipsquiggle在评论中提到的那样，正如我在旧答案中提到的那样，您实际上可以将启动配置直接保存为项目目录中的共享文件。然后，所有启动配置都可以像其他项目文件一样进行版本控制。（来自博客文章提示：从KD 创建和共享启动配置）

Answer 2

我目前正在开发一个项目，我们在源代码管理下拥有.project和.cproject文件。我们的想法是，与库路径和链接指令相关的设置将在整个团队中传播。在实践中它没有很好地工作，合并几乎总是回到冲突状态，需要在eclipse之外解除冲突，然后项目关闭并重新打开以使更改生效。我不建议将它们保存在源代码管理中。

Answer 3

有些项目，比如那些使用Maven的项目，比如基于POM生成.project文件。也就是说，除此之外 - .metadata不应该在源代码管理中。根据您计划管理标准的方式，您的项目必须确定projectdir / .settings是否有效。如果您可以诚实地信任您的开发人员根据标准设置他们的环境，并且您不必为任何项目定制任何特殊的环境，那么您就不需要将它们放入。我，我建议专门配置每个项目。这允许开发人员在同一工作区中处理多个项目的内容，而无需来回更改默认设置，并且它使设置非常明确，覆盖其默认设置以匹配项目的标准。只有困难的部分是确保它们都保持同步。但在大多数情况下，您可以将.settings文件从项目复制到项目。如果您在源代码管理中有任何特别不需要的内容，请执行相应的设置svn：ignore，如果您的SCM支持它。