文件.settings/org.eclipse.jdt.core.prefs是项目的一部分还是个人日食配置的一部分？
我应该将它添加到版本控制吗？
答案 0 :(得分：23)
是的，你应该。如果此文件不受版本控制，那么您无法创建同一项目的可重现版本，因为它不再是自包含的，而是取决于您的特定Eclipse安装及其设置。
如果将此项目导入另一个工作区（在您或任何其他计算机上），它可能会表现完全不同，因为编译器合规性设置，编译器警告配置和许多其他内容突然丢失或不同。很可能这样一个项目突然在新工作区中显示警告/错误，而之前完全没问题。
注意：这也要求您实际配置Project属性中的所有Java相关设置。切勿在Window - ＆gt;下使用Java编译器设置。如果你想拥有自包含的项目，可以选择首选项。
举一个具体的例子：如果您已将项目编译器合规性级别配置为Java 6，因为您正在使用Java 6特定功能（如在接口上覆盖注释），那么项目将create a lot of compile errors在其他上人民机器。这是因为每个Eclipse工作空间中的默认编译器合规性级别是Java 1.5，而在Java 1.5中，根本不允许覆盖注释。
这与您是否正在开发闭源或开源无关，如另一个答案中所示。
答案 1 :(得分：13)
与@ nitind的观点相反，没有。您不应在版本控制下放置任何特定于IDE的设置。除了您正在开发IDE功能或插件。
如果您真的拥有强制性的团队范围的IDE设置，将它们置于版本控制之下将是一个好主意，但IMO具有强制性的团队范围设置本身并不是一个好主意。
对于所有其他情况，共享IDE设置对于可移植构建是不利的，即使使用相同的IDE，也不会对其他IDE的用户起作用。
编辑：我应该区分，具体取决于项目的目标群体。如果您正在使用eclipse开发团队中的闭源产品，那么将这些首选项保留在版本控制之下是有帮助的，也是一个好主意。如果您正在开发库，封闭或开源或开源项目，我会考虑忽略更合适和礼貌的偏好。
编辑2：我担心@Bananenweizen会误解我想说的话。我知道这些设置是eclipse编译器设置。它们仍然是特定于IDE的，因为它们不会对Netbeans或IntelliJ产生任何影响，因为它们不会对命令行中的ant或maven构建产生任何影响。
是的，将这些设置保留在版本控制之外可以在不同的机器上为eclipse带来许多红色波浪线。它不会，如果它是一个具有设定源级别的maven项目，我不确定蚂蚁。
Eclipse不是自己构建项目 - 如果它是eclispe或ant项目，则使用ant构建它们，如果是maven项目，则使用maven构建它们。 ant和maven都有源版本的特定设置，不依赖于IDE。
这就是这些设置应该在构建文件中的位置。构建文件应该在源代码管理下。我之前提到的例外情况仍然适用。
答案 2 :(得分：1)
将其置于版本控制之下是一个问题.... 如果您导入并打开一个项目，Eclipse会在触摸 <。em>文件夹中的文件时，调用IProject.open（...）时... <在您可以在IProject对象上注册团队提供程序之前。这意味着validateEdit 将不会触发，如果您在弹出窗口中单击“是”或“否”，询问“您是否要使其可写”，则会出现恼人的错误。对于乐观的文件锁定提供者来说，这一切都很好，但对于“悲观”的提供者来说却没有那么好。对我们来说，这只是另一次日食烦恼。
如果由我决定，没办法我会把它们放在源代码管理中。
答案 3 :(得分：0)
答案是“是”，在这里您可以找到它的动机和正确的方法：watch the talk“提交IDE元文件：误解，误解和解决方案。”或者查看AurélienPupier的slides EclipseCon Europe 2015 @apupier（Eclipse专家高级软件工程师）。