合并IntelliJ IDEA .IPR和.IWS文件 [英] Merges on IntelliJ IDEA .IPR and .IWS files
问题描述
我们将IntelliJ .IPR和.IWS文件保存在我们的源代码管理中，但只需打开它们就可以通过IntelliJ进行修改，即使没有对项目进行任何工作也是如此。
We keep our IntelliJ .IPR and .IWS files in our source control, but they keep getting modified by IntelliJ just by opening them, even without any work being done on the project.
我们做错了什么？
推荐答案
我们保留IntelliJ .IPR和.IWS文件在我们的源代码管理中，但是只要打开它们就可以通过打开它们来修改它们，即使没有在项目上做任何工作。
"We keep our IntelliJ .IPR and .IWS files in our source control, but they keep getting modified by IntelliJ just by opening them, even without any work being done on the project."
.IWS文件肯定是每个开发人员文件，所以它不应该在源代码管理下。
The .IWS file is definitely a per developer file so it shouldn't be under source control.
对于最近项目中的.IPR文件，我们最初尝试对此文件进行版本化处理，就像使用.Net项目和VS.Net .SLN一样。文件。我们的目标是在15分钟内让开发人员在干净的PC上运行并运行，包括安装IDE或本地数据库等相关软件所需的时间。最后我们花了一些时间来调整本地配置，如下所示。
As for the .IPR file on a recent project we initially tried to version this file approaching it conceptually as you would with a .Net project and the VS.Net .SLN file. Our goal was to get a developer up and running on a clean PC within 15 minutes including the time it takes to install dependent software like the IDE or a local database. In the end we came close with some time to tweak the local configuration as per below.
问题是.IPR文件存储的设置多于.sln文件-eg各个插件的设置。因此，覆盖的主要原因是如果具有不同插件配置的开发人员打开IPR文件，则会将插件的一些默认设置写入该文件。我们觉得开发人员不应该将自己局限于给定的插件超级集（只是最小配置）。
The problem is the .IPR file stores more settings than a .sln file -eg settings for individual plugins. So a major cause for the overwrites is if a developer with a different plugin configuration opens the IPR file some default settings for the plugin are written to the file. We felt developers should not have to restrict themselves to a given plugin super set (just a minimum configuration).
我们缓解问题的方式（虽然没有完全解决）是切换到.idea文件夹格式。这将获取.IPR文件的内容，并将许多节点拆分为.idea子文件夹中的单个文件和文件夹。从这里我们能够从源代码控制中排除许多经常写入的文件。我们排除的部分文件包括：
The way we alleviated the problem (although not entirely solved) was to switch to the .idea folder format. This takes the content of the .IPR file and splits many of the nodes into individual files and folders in the .idea sub-folder. From here we were able to exclude many of the frequently written to files from source control. Some of the files we excluded were:
- workspace.xml
- dataSources.xml
- sqlDataSources.xml
- dynamic.xml
- workspace.xml
- dataSources.xml
- sqlDataSources.xml
- dynamic.xml
部分文件我们希望IntelliJ独自离开（虽然责任也可以归到插件开发者而不仅仅是Jetbrains）：
Some files we'd like IntelliJ to leave alone are (although the blame can also go to the plugin developers and not just Jetbrains):
- projectCodeStyle。 xml（所以我们可以在项目中获得一致的代码格式 - 再次根据开发人员的本地插件组合覆盖它。）
- runConfigurations文件夹下的任何文件。配置运行配置可能非常耗时，特别是如果您有一个具有多个方面的复杂应用程序。通过简单地打开IDE或构建来改变最常见的愚蠢的事情是RunnerSettings下的DEBUG_PORT选项。我的意见是，如果它是动态分配的，为什么没有动态值？
- misc.xml。该文件还包含插件配置。有些设置看起来很方便分享，而其他设置看起来更适合个人配置。例如，IvyIDEA插件为您的常春藤配置文件提供绝对路径。
- 模块文件。这些大部分都是独立的，但是不必要的覆盖的一个例子是IvyIDEA插件，它将本地ivy-cache位置的详细信息放入此文件中。但这又是插件的错，而不是真正的Jetbrains。
- projectCodeStyle.xml (so we can get consistent code formatting in the project - again this can be overwritten based on a developer's local plugin mix).
- any file under the runConfigurations folder. It can be time consuming to configure run configurations particularly if you have a complex app with many facets. The most commonly stupid thing that gets changed by simply opening the IDE or building is the "DEBUG_PORT" option under RunnerSettings. My opinion is if it's dynamically allocated why not have a value of "Dynamic"?
- misc.xml. This file also contains plugin configuration. Some settings look handy to share and others look more for personal config. Eg the IvyIDEA plugin puts an absolute path to your ivy config file.
- The module files. These are mostly left alone but an example of needless overwritting is the IvyIDEA plugin putting details of the local ivy-cache location in this file. But again this is the plugin's fault and not really Jetbrains.
希望这有帮助。
Christian。
Christian.
这篇关于合并IntelliJ IDEA .IPR和.IWS文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
