"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."
The .IWS file is definitely a per developer file so it shouldn't be under source control.
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.
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).
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
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 (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.
Hope this helps.
Christian.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
