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

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

唯一的例外是 .launch XML文件(启动程序定义)。

它们在

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

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

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

(警告:做 取消选中“删除关联资源时删除配置”选项。 在 跑 / 发射 / 启动配置 首选项面板:软删除一个项目以再次导入它是很常见的-强制重新初始化Eclipse元数据。但如果选中此选项,将删除详细的启动参数!)

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

应该在你的供应链中(特别是 .project 和 .classpath 根据 Eclipse documentation )

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

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

注:最好是 project-dir 指的是“外部”项目目录,而不是在Eclipse工作区下创建的目录。这样,两个概念(Eclipse工作区和SCM工作区)就可以清楚地分开。

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

(来自博客帖子 Tip: Creating and Sharing Launch Configurations 来自KD)

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

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

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

不值得这么做 CDT 配置文件不支持源代码管理。.cproject文件有一个bug文件,经常更改并导致冲突,请参见 Sharing cdt-project files in repository always causes conflicts .

有些项目,比如使用maven的项目,喜欢基于poms生成.project文件。

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

唯一困难的是确保它们保持同步。但在大多数情况下,您可以将.settings文件从项目复制到项目。如果在源代码管理中有您特别不想要的,请执行与设置svn:ignore等效的操作,如果您的SCM支持的话。

.classpath文件无疑是签入SCM的一个很好的候选文件,因为手工设置它可能需要很多工作,而且对于新开发人员来说很难进入项目。的确,它可以从其他来源生成,在这种情况下,您将签入其他来源。

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

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

我不想说这些。它们很可能包含仅与您的工作站相关的信息(我正在考虑库和所有库的路径)。另外,如果团队中有人不使用Eclipse呢?

考虑:

.classpath
.project
.launch

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

您可能会尝试在版本控制中包含.metadata,这样Eclipse开发人员可以签出整个工作区,并将其与所有正确的项目进行预配置,但它包含许多用户特定的信息,任何人在使用它时,它都会发生变化,因此我建议不要包含.metadata。只需导入所有现有的Eclipse项目,就可以轻松地构建本地工作区。

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

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

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