该文件.settings/org.eclipse.jdt.core.prefs是项目的一部分还是我个人 Eclipse 配置的一部分？
我应该将它添加到版本控制中吗？
问问题
14342 次
4 回答
29
是的你应该。如果此文件不受版本控制，那么您无法创建同一项目的可重现构建，因为它不再是自包含的，而是取决于您的特定 Eclipse 安装及其设置。
如果您将此项目导入另一个工作区（在您或任何其他机器上），它的行为可能会完全不同，因为编译器合规性设置、编译器警告配置和许多其他东西突然丢失或不同。这样的项目很有可能突然在新工作区中显示警告/错误，而之前完全没问题。
注意：这还需要您在项目属性中实际配置所有与 Java 相关的设置。如果您想拥有自包含项目，切勿使用 Window -> Preferences 下的 Java 编译器设置。
举一个具体的例子：如果您将项目的编译器合规级别配置为 Java 6，因为您使用的是 Java 6 的特定功能（例如在接口上覆盖注释），那么该项目将在其他人的机器上产生很多编译错误. 这是因为每个 Eclipse 工作区中的默认编译器合规级别是 Java 1.5，而在 Java 1.5 中，根本不允许 Override 注释。
如另一个答案所示，这与您是在开发封闭源代码还是开放源代码无关。
于 2013-04-11T06:37:05.810 回答
16
与@nitind 的观点相反，不。您不应将任何特定于 IDE 的设置置于版本控制之下。除非您正在开发 IDE 功能或插件。
如果您确实有强制性的团队范围的 IDE 设置，将它们置于版本控制之下是一个好主意，但 IMO 具有强制性的团队范围的设置本身并不是一个好主意。
对于所有其他情况，共享 IDE 设置不利于可移植构建，即使使用相同的 IDE 也是如此，而且对于其他 IDE 的用户来说充其量也是无用的。
编辑：我应该区分，具体取决于您项目的目标群体。如果您正在使用 eclipse 的团队中开发一个封闭源代码产品，那么将这些偏好设置在版本控制之下是有帮助的，也是一个好主意。如果你正在开发一个库、封闭或开源，或者一个开源项目，我认为忽略偏好更合适和礼貌。
EDIT2：恐怕@Bananenweizen 误解了我想说的话。
我知道这些设置是eclipse编译器设置。它们仍然是特定于 IDE 的，因为它们不会对 Netbeans 或 IntelliJ 产生任何影响，因为它们不会对命令行中的 ant 或 maven 构建产生任何影响。
是的，将这些设置排除在版本控制之外可能会在不同机器上的 Eclipse 中为您带来许多红色波浪线。它不会，如果它是一个具有设置源级别的maven项目，我不确定ant。
Eclipse 不会自行构建项目——如果它是 eclispe 或 ant 项目，它会用 ant 构建它们，如果它是 maven 项目，它会用 maven 构建它们。ant 和 maven 都有不依赖于 IDE 的源版本的特定设置。
这就是这些设置应该在的地方 - 在构建文件中。并且构建文件应该在源代码控制之下。我之前提到的例外情况仍然适用。
编辑 2020.03.15 @howlger 告诉我，这些以前的 eclipse 专有文件的可用性已经提高。它们可以在 VSCode 和 IntelliJ 中使用。这提高了它们在 IDE 中有用的机会，并且可能会改变您共享它们的决定。
IMO，这些文件令人担忧。虽然我支持将源代码级别和代码格式化作为构建的一部分，但我认为问题突出显示规则、保存操作和类似问题超出了范围。如果可能的话，我将它们分开，通过将它们放入构建定义来共享前者，而不是后者。
于 2013-04-10T14:00:48.100 回答
2
这是将其置于版本控制之下的问题....如果您导入并打开一个项目，Eclipse 坚持在触摸.settings 文件夹中的文件时调用 IProject.open(...) ......这是在您可以在 IProject 对象上注册团队提供者之前。这意味着 validateEdit不会触发，并且无论您在弹出窗口中单击“是”还是“否”都会出现烦人的错误，询问“你想让它可写吗？” 对于乐观的文件锁定提供者来说，这一切都很好，但对于“悲观”的提供者来说就没那么好了。对我们来说，这只是另一个日食烦恼。
如果由我决定，我不可能将这些放在源代码管理中。
于 2013-09-04T13:21:07.510 回答
1
答案是“是”，在这里您可以找到这样做的动机和正确的方法：观看“提交 IDE 元文件：误解、误解和解决方案”讲座。或查看Aurélien Pupier @apupier（高级软件工程师，Eclipse 专家）在 2015年EclipseCon Europe上的相应幻灯片。
于 2018-02-21T13:15:57.480 回答