我正在运行一个开源 java 项目，该项目由依赖树中的多个模块组成。所有这些模块都是 subversion 存储库中的子目录。对于我们项目的新手来说，在 eclipse 中手动设置所有这些需要做很多工作。
并非我们所有的开发人员都使用 eclipse。尽管如此，我们正在考虑只签入 .classpath 和 .project 文件以帮助新手入门。这是一个好主意吗？或者这会导致这些文件中的持续冲突吗？是否有另一种方法可以使项目易于在 Eclipse 上设置？
【问题讨论】：
标签： eclipse version-control ide
绝对是的，正如我在“Do you keep your project files under version control?”中所说的那样
“加载，设置，开始。”
但是...这实际上仅适用于最近的 Eclipse3.5 设置，其中构建路径支持相对路径：
Eclipse3.6 会更好，因为它支持Linked Resources 中路径变量的相对路径：
（自 3.6M5 起）
【讨论】：
绝对不——通过颠覆分发项目文件通常是一个糟糕的主意。特别是因为有人可能会以某种奇怪的方式修改它们。项目文档中的一个好页面是一个更好的主意。我们的项目也有许多模块和复杂的设置。我们已经建立了一个融合页面，描述如何在每个流行的 IDE（IntelliJ、Eclipse、NetBeans）上开始使用该项目。 Subversion 中的 README 文件包含相同的信息。
【讨论】：
我投反对票，但那是因为我通常会从 maven 生成这些文件
【讨论】：
根据我的经验，除了涉及纯本地设置的有限情况外，一切都应该在源代码管理中。源代码控制的法则是，所有推入的东西都应该被那些拉出来的人所期待。不幸的是，eclipse经常导致这样的事情出现在.classpath：
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>
所以在我的 Mac 上这是可行的，也许 Mac 上的某个人拥有相同的 JRE，但这对其他人不起作用。
此外，没有简单的方法可以解决这个问题。 Eclipse 将始终添加它。我希望在其中有 .classpath 文件，因为在我们关心版本控制的 lib 文件夹中有一些 3rd 方 JAR，所以我们将它们留在那里，这样新开发人员就不必得到它们.我们正在迁移到托管系统，但仍然签入了托管+非托管依赖项。这意味着所有开发人员只需确保两个目录位于他们的.classpaths 中。但这比每次拉取时都必须修复 JRE 并在每次提交时更改 .classpath 更好。
尽管如此，Eclipse 还为您做了一些其他的好事。 .project 文件通常在实例之间是相同的，所以包括它。但是关于 eclipse 源代码控制的最好的事情是运行配置设置。在 Run Configurations 对话框的“Common”选项卡下，保存配置，以便您的同事在 Debug 和 Run 的收藏夹列表下显示它们。对我来说，一堆.launch 文件放在.settings 目录中，所以我们都可以使用它们。
所以我说：.settings 目录进入启动配置的源代码控制（*.prefs 除外）
.classpath 置之不理
.project 进去。
【讨论】：
我会签入这些文件，以使新用户的入门尽可能容易。充其量用户应该检查项目并且应该能够在没有额外知识的情况下运行它。对于此文件，规则与项目中其他文件的规则相同：小心处理。您不应该在源代码中放置绝对路径，也不应该在配置文件中放置。
如果以项目从头开始运行的方式签入文件，则不应该有太多的力量来更改它们。
【讨论】：
如果文件不包含绝对路径和其他将它们直接绑定到单个开发人员环境的数据，我建议您将文件签入 subversion。
如果文件确实包含绝对路径等，README 将是更好的选择。
【讨论】：
是的，一定要签入，但请确保记录任何路径依赖关系并尽可能避免使用绝对路径。
如果您不签入，那么任何签出项目的人都需要重新创建所有这些设置，这很烦人并且可能容易出错。
一些复杂的设置最好由脚本处理以生成这些文件，但通常最好只签入。
【讨论】：