Merges on IntelliJ IDEA .IPR and .IWS files

问题:

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.

What are we doing wrong?

回答1:

"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.

回答2:

Without knowing exactly what is being changed, this is a little difficult to answer confidently, but I would say:

• IWS files contain information describing how a developer's IDE is arranged for this project (including such things as recent change history, the current state of each editor window, which dockable windows are visible and which have been collapsed). Given that each developer should be allowed to arrange their workspace however they like, these should not be in source control.

• IPR files describe the structure of the project code - by this I mean things like which modules are part of the project, which build.xml files to use, where to find libraries to compile your code etc. This can be in source control, but if you allow these settings to vary from one developer's copy of the project to the next, you'll be in for a rough ride.

If you have a libraryTable component inside your IPR file:

Almost certainly what is happening is that each developer is keeping shared libraries (JARs) - required to build their code - on their local machine in different places; when they commit changes, the location of their libraries is being written to the IPR file. If you were to do this, when I updated the project, my copy of the IPR and yours would conflict on the locations of these JARs.

We get around this problem by locating JAR files in a shared location (such as a mapped network drive) and then ensuring that every developer downloads these files to the same place (a lib subfolder under the project root works well). The downside is that you end up with multiple copies of the same JAR across projects (each project will reference its own lib folder), but on the upside, as every developer is using the same project structure, updating IPRs should work a lot better.

Otherwise:

Have a look to see what IntelliJ is trying to merge (when you update, you should be given the option to manually merge the files or view differences, otherwise use your favourite diff tool). If you could update your question with a bit more info about what your merge conflicts look like, it might make it easier to see where the wheels are coming off.

回答3:

We add an extension to the ones checked into source control (.deleteme). Then new people can check out the project, change the extensions, and go. If we make config changes, we update the checked in files.

回答4:

One solution is to not put your IntelliJ projects in source control. This implies that they're easy to recreate.

You can tell Subversion about files that it should ignore. Add your IntelliJ files to that list.

"...even without any work being done on the project...." - this suggests that you frequently open IntelliJ without doing any useful work on the project. Maybe that's the real issue. I can't see why you'd open the IDE without doing SOMETHING that would be worth checking in. And what's the cost of a rising revision number? Small, in my opinion.

So now I've changed my mind. Check in IntelliJ project files, and don't worry about rising revision numbers. They aren't costing you much.