我有一个Java项目，我想提交到我的SVN存储库，使用eclipse创建。
现在，哪些文件（显然除了源代码）是必要的？在工作区根目录中，有一个包含许多文件和子文件夹的.settings文件夹，在项目文件夹中有两个文件 - .classpath和.project，另一个.settings文件夹包含一个文件 - org.eclipse.jdt.core .prefs。
哪些文件应该提交给SVN，哪些文件可以安全地排除？
我有一个Java项目，我想提交到我的SVN存储库，使用eclipse创建。
现在，哪些文件（显然除了源代码）是必要的？在工作区根目录中，有一个包含许多文件和子文件夹的.settings文件夹，在项目文件夹中有两个文件 - .classpath和.project，另一个.settings文件夹包含一个文件 - org.eclipse.jdt.core .prefs。
哪些文件应该提交给SVN，哪些文件可以安全地排除？
如果您希望在整个团队中拥有一致的设置，它们都非常有用。
.classpath 和 .project 意味着只需导入项目，每个人都可以启动并运行项目。每个人在签入时都会对项目中包含的库和源文件进行任何更改。
该 .settings 目录包含代码格式化选项以及编译器认为是警告，错误或确定的内容。为了保持一致性，我也开始检查这些内容（只要团队中的每个人都同意格式化标准，我猜）。
我发现在Eclipse中跨版本控制共享内容的最大限制是在库定义中。库定义似乎只存储在每个用户的基础上，因此如果您在.classpath文件中引用“库”，则每个其他用户必须手动定义该库的内容（或手动导入导出的库定义文件） 。
编辑： （解决@mliebelt的评论如下）
如果您试图在开发人员之间保持一致性/标准化，则只提交.settings文件。如果这不是项目的问题，那么不提交.settings文件就不用担心维护了。可能不需要提交特定于个人喜欢的插件的文件（虽然我不认为如果它们会受到伤害，可能会被忽略？）。
我发现值得承诺的两个最常见的是 org.eclipse.jdt.core.prefs 和 org.eclipse.jdt.ui.prefs，它是任何（Java）Eclipse项目的核心。
如果您希望在整个团队中拥有一致的设置，它们都非常有用。
.classpath 和 .project 意味着只需导入项目，每个人都可以启动并运行项目。每个人在签入时都会对项目中包含的库和源文件进行任何更改。
该 .settings 目录包含代码格式化选项以及编译器认为是警告，错误或确定的内容。为了保持一致性，我也开始检查这些内容（只要团队中的每个人都同意格式化标准，我猜）。
我发现在Eclipse中跨版本控制共享内容的最大限制是在库定义中。库定义似乎只存储在每个用户的基础上，因此如果您在.classpath文件中引用“库”，则每个其他用户必须手动定义该库的内容（或手动导入导出的库定义文件） 。
编辑： （解决@mliebelt的评论如下）
如果您试图在开发人员之间保持一致性/标准化，则只提交.settings文件。如果这不是项目的问题，那么不提交.settings文件就不用担心维护了。可能不需要提交特定于个人喜欢的插件的文件（虽然我不认为如果它们会受到伤害，可能会被忽略？）。
我发现值得承诺的两个最常见的是 org.eclipse.jdt.core.prefs 和 org.eclipse.jdt.ui.prefs，它是任何（Java）Eclipse项目的核心。
您可以排除.settings文件夹，但.project文件对于想要重建相同的Eclipse项目的其他开发人员非常有用。如果检查文件，它应该只有相对引用（如果没有，你应该修改它。）
与其他答案相比，我已经获得了更好的体验 没有检查.project 在我使用的大型开源项目中存档。
您可能不同意我的意见，但共享.project文件存在一个问题：它们包含对项目中使用的项目性质的引用。项目性质再次取决于本地开发人员机器上安装的插件。
示例：如果在Java项目中使用Findbugs，则会在Java项目中添加新的特性。检查该文件，在另一个系统上修改它（没有安装Findbugs），然后再次在我的系统上使用它导致Findbugs引用丢失（因此所有Findbugs检查都被静默删除）。
但是，如果您可以让所有开发人员同意使用相同的工具，那么您可以轻松解决此问题。