提问



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


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



  .metadata/*结果
  项目DIR/。工程结果
  项目DIR/的.classpath结果
  项目DIR/.settings/*



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

最佳参考


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


唯一的例外是.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文档。)[8]


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


为此，您希望在.classpath中仅使用相对路径，使用链接资源。


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




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


(来自博客文章提示:从KD创建和共享启动配置)[12]




其它参考1


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


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


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

其它参考2


CDT配置文件对源代码控制不友好是没有价值的。有.cproject文件变更非常频繁且导致冲突的bug，请参阅在存储库中共享cdt-project文件总是会导致冲突 [13] [14]

其它参考3


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


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


只有困难的部分是确保它们都保持同步。但在大多数情况下，您可以将.settings文件从项目复制到项目。如果您有任何特别不想要的源代码控制，请执行相应的设置svn:忽略它们，如果您的SCM支持它。

其它参考4


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


至于.settings，它取决于设置。这是一个灰色区域，但是一些设置几乎是强制性的，并且能够检查项目，在Eclipse中导入并完成所有设置并且很好。


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

其它参考5


我不会说他们中的任何一个。他们很可能包含仅与您的工作站相关的信息(我正在思考图书馆和所有人的路径)。如果团队中有人不使用Eclipse，那该怎么办?

其它参考6


考虑:


.classpath
.project
.launch


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


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

其它参考7


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


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



  • 已安装的JRE及其名称

  • 服务器运行时环境

  • Java编辑器模板

  • 版本控制键盘快捷键

  • 不提供项目特定设置的插件设置

  • Maven设置

  • 预先配置的观点

  • ...