27

我们将 IntelliJ .IPR 和 .IWS 文件保存在我们的源代码控制中，但只要打开它们，它们就会不断被 IntelliJ 修改，即使没有对项目进行任何工作。

我们做错了什么？

4

4 回答 4

42

“我们将 IntelliJ .IPR 和 .IWS 文件保存在我们的源代码控制中，但只要打开它们，它们就会不断被 IntelliJ 修改，即使没有对项目进行任何工作。”

.IWS 文件绝对是每个开发人员的文件，因此不应受源代码控制。

至于最近一个项目中的 .IPR 文件，我们最初尝试对这个文件进行版本化，在概念上接近它，就像使用 .Net 项目和 VS.Net .SLN 文件一样。我们的目标是在 15 分钟内让开发人员在干净的 PC 上启动并运行，其中包括安装 IDE 或本地数据库等依赖软件所需的时间。最后，我们接近了一些时间来调整本地配置，如下所示。

问题是 .IPR 文件存储的设置多于 .sln 文件 - 例如单个插件的设置。因此，覆盖的主要原因是如果具有不同插件配置的开发人员打开 IPR 文件，插件的一些默认设置将写入文件。我们认为开发人员不应该将自己限制在给定的插件超集（只是最低配置）。

我们缓解问题的方法（虽然没有完全解决）是切换到 .idea 文件夹格式。这将获取 .IPR 文件的内容并将许多节点拆分为 .idea 子文件夹中的单独文件和文件夹。从这里我们能够从源代码控制中排除许多经常写入文件的文件。我们排除的一些文件是：

  • 工作区.xml
  • 数据源.xml
  • sqlDataSources.xml
  • 动态的.xml

我们希望 IntelliJ 不理会的一些文件是（尽管责任也可能归咎于插件开发人员，而不仅仅是 Jetbrains）：

  • projectCodeStyle.xml（因此我们可以在项目中获得一致的代码格式 - 同样可以根据开发人员的本地插件组合覆盖）。
  • runConfigurations 文件夹下的任何文件。配置运行配置可能非常耗时，特别是如果您有一个包含许多方面的复杂应用程序。只需打开 IDE 或构建即可更改的最常见愚蠢的事情是 RunnerSettings 下的“DEBUG_PORT”选项。我的观点是，如果它是动态分配的，为什么不具有“动态”值？
  • 杂项.xml。该文件还包含插件配置。一些设置看起来很容易分享，而另一些则更适合个人配置。例如，IvyIDEA 插件为您的 ivy 配置文件放置了一个绝对路径。
  • 模块文件。这些大部分都被单独留下，但一个不必要的覆盖示例是 IvyIDEA 插件将本地 ivy-cache 位置的详细信息放在此文件中。但这又是插件的错，而不是真正的 Jetbrains。

希望这可以帮助。

基督教。

于 2009-06-23T07:35:23.227 回答
4

在不确切知道发生了什么变化的情况下，这有点难以自信地回答，但我会说：

  • IWS 文件包含描述如何为该项目安排开发人员的 IDE 的信息（包括最近的更改历史、每个编辑器窗口的当前状态、哪些可停靠窗口可见以及哪些已折叠）。鉴于应该允许每个开发人员按照他们喜欢的方式安排他们的工作区，这些不应该在源代码控制中。

  • IPR 文件描述了项目代码的结构——我的意思是，哪些模块是项目的一部分，要使用哪些 build.xml 文件，在哪里可以找到编译代码的库等。这可以在源代码控制中，但是如果您允许这些设置从一个开发人员的项目副本到下一个项目副本不同，那么您将陷入困境。

如果您的 IPR 文件中有 libraryTable 组件：

几乎可以肯定的是，每个开发人员都将共享库（JAR）——构建代码所需的——保存在不同地方的本地机器上；当他们提交更改时，他们的库的位置将被写入 IPR 文件。如果你这样做，当我更新项目时，我的 IPR 副本和你的 IPR 副本将在这些 JAR 的位置上发生冲突。

我们通过将 JAR 文件定位在共享位置（例如映射的网络驱动器）然后确保每个开发人员将这些文件下载到同一个位置（项目根目录下的 lib 子文件夹运行良好）来解决这个问题。不利的一面是，您最终会在项目中获得相同 JAR 的多个副本（每个项目将引用其自己的 lib 文件夹），但有利的一面是，由于每个开发人员都使用相同的项目结构，更新 IPR 应该会更好。

否则：

看看 IntelliJ 正在尝试合并什么（更新时，您应该可以选择手动合并文件或查看差异，否则使用您最喜欢的 diff 工具）。如果您可以使用有关合并冲突的更多信息来更新您的问题，则可能会更容易查看轮子脱落的位置。

于 2009-06-22T08:17:07.550 回答
1

我们为签入源代码管理 (.deleteme) 的文件添加扩展名。然后新人可以签出项目，更改扩展，然后继续。如果我们进行配置更改，我们会更新签入的文件。

于 2009-09-23T00:21:46.923 回答
0

一种解决方案是不要将您的 IntelliJ 项目置于源代码控制中。这意味着它们很容易重新创建。

你可以告诉 Subversion 它应该忽略的文件。将您的 IntelliJ 文件添加到该列表中。

“......即使没有对项目进行任何工作......” - 这表明您经常打开 IntelliJ 而不对项目做任何有用的工作。也许这才是真正的问题。我不明白为什么你会打开 IDE 而不做一些值得检查的事情。修订号增加的成本是多少？小，在我看来。

所以现在我改变了主意。签入 IntelliJ 项目文件，不必担心修订号上升。他们不会花费你太多。

于 2009-06-16T09:53:55.280 回答