logo标签列表

.classpath和.project文件-应该提交到版本控制中还是不提交？

eclipseversion-controlide
93

我正在运行一个由多个模块组成的开源Java项目，这些模块存在依赖关系树中的子目录中，存储在Subversion仓库中。对于我们项目的新手来说，在Eclipse中手动设置所有这些内容需要花费很多工作量。

并非所有的开发人员都使用Eclipse。尽管如此，我们考虑只需将.classpath和.project文件检入以帮助新手开始工作。这是一个好主意吗？还是会导致这些文件的不断冲突？是否有其他方法可以使该项目在Eclipse上轻松设置？

1
可能是重复的问题：我应该将我的项目文件放在版本控制下吗？ - Steve Chambers
@SteveChambers同意，另一个问题是2年前的。奇怪的是这个问题没有被关闭，而更早的那个被关闭了。 - questionto42
7个回答
68

毫无疑问，正如我在“你是否将项目文件保留在版本控制下？”中所说的那样。

"加载它，设置它，开始吧。"

但是...这只适用于最近的Eclipse3.5设置，其中构建路径支持相对路径：

Build path supports relative paths

而Eclipse3.6将更好，因为它在Linked Resources中支持路径变量的相对路径：

path variable with relative path
（自3.6M5以来）

2
哇，我不知道他们加了这个...本来可以节省我们一些麻烦的。 - Uri
看起来与此答案相关联的图片已经离线。 - vkraemer
1
@vkraemer：没错。我现在已经恢复了这两张图片，第一张来自http://archive.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/eclipse-news-part2.html，第二张来自http://download.itemis.com/mirror/eclipse/R-3.6-201006080911./eclipse-news-part1.html。 - VonC
19

绝对不行 - 通过Subversion分发项目文件通常是一个糟糕的主意。特别是因为某些人可能以一些奇怪的方式修改它们。在项目文档中编写一个好的页面是一个更好的主意。我们的项目还有许多模块和复杂的设置。我们设置了一个Confluence页面，描述如何在每个流行的IDE上开始使用该项目 - IntelliJ、Eclipse、NetBeans。Subversion中的README文件包含相同的信息。

34
我不同意。从我的经验来看，将这些文件提交到版本控制系统可以使检出过程变得更加容易。有人可能以某种奇怪的方式更改它们？有人可能以某种奇怪的方式更改您的代码... - Arne Deutsch
Arne，你应该把那个变成答案，而不是评论。 - amarillion
6
任何IDE的项目文件实际上并不是项目的一部分，如果想要分发它们，请将它们附加到我提到的文章中。通常团队中的每个成员都可以修改repo中的文件，但不是每个人都能够附加新文件到重要文档节点等位置。有些人很容易忘记忽略classpath和项目文件，并在不应该提交它们的时候提交。即使您将它们保留在subversion中，也应该确保将它们放在某个地方备份。 - Bozhidar Batsov
8
很反感，项目设置是日常工作中至关重要的一部分。意外检入错误设置的缺点比自动使所有人保持最新的优点小得多。毕竟，您总是可以轻松地返回以前的版本。 - Michael Borgwardt
7
每个人都有权发表自己的意见。事实上，我从一开始就不会依赖于Eclipse（或任何其他IDE）的项目系统来创建项目……Maven是终极项目理解工具，并使IDE特定设置过时。顺便说一句，发现当前设置有问题并返回到以前版本的时间可能与自己调整任何新设置的时间相同。至少在我们公司，团队中的每个人都会通过电子邮件收到通知，如果某些用户干预需要进行较大的更改后。 - Bozhidar Batsov
Eclipse FAQ指出，您应该添加它们：https://wiki.eclipse.org/FAQ_How_do_I_set_up_a_Java_project_to_share_in_a_repository%3F - Stefan
11

我投反对票，因为我通常会从Maven生成这些文件。

m2e 为你提供了大部分但不是全部的功能。 - Junchen Liu
6

根据我的经验，除了仅涉及本地设置的有限情况外，所有内容都应该放在源代码控制中。源代码控制的法则是，所有推送进去的内容都应该能被拉取出来的人正常工作。不幸的是，eclipse 经常会将这些内容放在 .classpath 文件中：

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

在我的Mac上这个可以用，或许其他使用同样的JRE的人也可以用，但是其他人都不能用。
同时，没有轻松的解决方法。Eclipse总是会添加进去。我们想要把.classpath文件放在那里，因为我们的lib文件夹中有一些第三方JAR包，其中我们关心版本控制，所以我们把它们留在那里，这样新开发者就不用下载它们了。我们正在转向管理系统，但还是有管理和未管理的依赖性被检查。这意味着所有开发者只需要确保两个目录在他们的.classpath中即可。但这比每次拉取时都要修复您的JRE，并且每次提交时都要更改您的.classpath更好。
Eclipse还有一些很好的功能。.project文件通常在各个实例之间都是相同的，所以请包含它。但是对于eclipse的源代码控制来说，最好的事情是运行配置设置。在运行配置对话框的“常规”选项卡下，保存配置，以便它们出现在您的同事的Debug和Run的收藏列表中。对我而言，一堆.launch文件存储在.settings目录中，所以我们都可以使用它们。
所以我说：.settings目录放到源代码控制中以进行启动配置（除了*.prefs）。
.classpath不需要。
.project文件在其中。
即使使用JRE/JVM的执行环境，这种情况也是成立的吗？ - Mr_and_Mrs_D
5

我会检查这些文件，以使新用户的入门尽可能容易。最好的情况是用户可以检出项目并能够在不需要额外知识的情况下运行它。对于这些文件，规则与项目中的其他文件相同：要小心处理。您不应该在源代码中放置绝对路径，也不应该在配置文件中放置。

如果文件以一种使得项目从头开始运行的方式进行检入，则不需要花费太多力气来更改它们。

5

如果文件中不包含绝对路径和其他直接与单个开发环境相关的数据，我建议您将它们检入到Subversion。

如果文件中包含绝对路径等内容，则最好选择README文件。

3

是的，一定要将它们检入，但确保记录任何路径依赖，并尽可能避免使用绝对路径。

如果您不检入它们，则检出项目的任何人都需要重新创建所有这些设置，这很麻烦，可能会出错。

一些复杂的设置可能更适合使用脚本来生成这些文件，但通常最好只是将它们检入。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接