41

The project is using Maven so the POM files are the main sources of project info. There are some useful settings in the project files which would be nice to keep.

OTOH IDEA seems to create too many redundant changes in the project file structure which pollutes the SVN history and sometimes creates conflicts.

Should I keep the .idea directory and the *.iml files under version control? in full? in part?

Update: So the best practice I have found working for me and my team is so far:

  1. Check in all IDEA files, *.iml and .idea directories. They contain valuable information and it's a waste of time to recreate it each time you update.
  2. Create private branch for every developer
  3. cd into .idea directory
  4. svn switch it to its private branch counterpart
  5. Don't check in IDEA files on regular commits -- they pollute history. Check them in on special commits.

This way, you keep the content of .idea directory in version control but keep it out of the way of regular commits. Any developer can have access to anybody else's IDEA directories.

Update 2: Since this question was written, I have changed my practice to not checking in any IntelliJ files into the version control, as advised by many responders. This is my current practice for both Maven and Gradle. The tools have developed to the point that the critical information can always be reproduced from the original .POM or .gradle files. When the files change, the IDE tracks changes reliably so you don't lose your IDE files that often so there is no need to check them in.

Update 3: 7 years after asking this question it seems to be still relevant. The same best practices apply to Gradle as well (probably SBT, too): don't check IDE files in, recreate them as necessary from the basic POM, .gradle or SBT files.

Sasha O
  • 3,710
  • 2
  • 35
  • 45
  • 1
    Thanks everyone for your suggestions. In the meantime my best practice is to check the IDEA files in but as a separate changeset so that it would not mess up the SVN history that badly. I usually give these changesets the name "IDEA madness" :-) – Sasha O Jan 29 '10 at 23:37
  • 1
    see http://stackoverflow.com/questions/3041154/intellij-idea-9-10-what-folders-to-check-into-or-not-check-into-source-contro -> IDEA FAQ: http://devnet.jetbrains.com/docs/DOC-1186 – Matthew Cornell Apr 10 '13 at 14:53
  • @MatthewCornell perhaps upgrade your comment to answer? – Jonas Berlin Oct 05 '16 at 11:22

6 Answers6

17

Short answer: don't put these files in the source control repository as you can "generate" them (and this is even more true if you don't need them, if they are annoying, if they can break others environment).

I personally use the following values for svn:ignore: 

target 
*~ 
*.log 
.classpath 
.project 
*.ipr 
*.iws 
*.iml 
.settings
Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • 5
    This answer ignores the value of having iml files right just after check out/update.I've seen a lot of time wasted by developers, that had to figure out, that they need to regenerate imls after update. Putting them into the VC is actually kind to others. Blindly following the general "don't commit generated stuff" rule makes only harm here. – Przemek Pokrywka Jun 12 '11 at 07:54
  • 3
    Unless I'm way off base here, many of the settings in the .idea directory cannot simply be regenerated. We're talking about how a project is split up into modules, which modules have what facets attached, what artifacts need to be generated, what is the build process, etc. This is key information. Now, if you can generate all of this information from other files, then consider going that route, but for the question here, I'm not seeing that. – David J. Sep 17 '11 at 00:36
  • 1
    That is not valid for big projects that involves lot of people. In our case for example we also store there the inspections that idea perform and the code format style. – Mikel Dec 01 '11 at 21:15
  • 4
    Actualy, IDEA Project (.ipr) and IDEA Module (.iml) files are designed to be shared, so you should check them into source control. There is also an IDEA Workspace (.iws) file that should not be shared. – James Tikalsky Dec 16 '11 at 21:34
15

One of the great things about Maven is that the tool support exists for turning a POM into a native project in Eclipse, Idea and Netbeans. If you have a pom, you can create a native project pretty quickly.

For that reason, I wouldn't check in .idea or *.iml files under source control any more than I would check in RMI stubs or class files.

sal
  • 23,373
  • 15
  • 66
  • 85
14

I think you should put .idea directory into version control. Most of the configuration contained there should be version tracked, e.g. compiler configs.

The only file that doesn't belong to version control is .idea/workspace.xml, because it only contains configuration particular to your local environment.

IntelliJ Idea actually puts workspace.xml into ignore list by default, so if you use Idea to check in, you should be all set without changing anything.

alexei.vidmich
  • 571
  • 1
  • 5
  • 12
  • This actually was the reason for the original question: .idea is what I use (no workspace.xml of course) and it generates changes all the time. These change mess up history and make me deal with them too much. How can I cut down on these changes? – Sasha O Dec 14 '09 at 20:01
  • I used this approach for a few days and didn't notice any unwanted changes in that area. Do you have examples of what you call redundant changes polluting SVN history, which are under .idea directory but outside of workspace.xml? – alexei.vidmich Dec 15 '09 at 07:05
  • Alexei, here is one example of redundant checkin. No changes were done to the project. http://ow.ly/d/1g7 – Sasha O Jan 14 '10 at 23:24
  • 2
    Sasha, Here is what I see: - addition or change of scope for a library. When 1 out 10 people on the team adds a library to the project, I want the rest 9 developers to get this update, rather than figure this out manually. - /target/work is not excluded any more. Same thing, I want this change to propagate. - compiler settings changes. Not sure, it might have been an artifact of IDEA version upgrade or an intentional change. – alexei.vidmich Mar 10 '10 at 05:07
  • Alexei, as I said, no changes were done to the project at all, yet IDEA somehow decided to change the files. Maybe this happens because different developers use different version of IDEA but I don't want to decree a certain version of software for developers to use. Anyway, I think I found better solution. I am trying it now, will report in a few days. – Sasha O Mar 16 '10 at 03:30
  • What is the better solution you've been investigating Sasha ? – Gilles Philippart Feb 21 '11 at 14:55
  • I'm on a project now where not having a standard IDE build causes some pain among different developers. Putting most of the .idea files in source control, like Alexei suggests here, is a really good idea. – David J. Sep 17 '11 at 00:34
9

I see that the standard answer is "don't check in the project file, just the .pom". But things like the .ipr files contain lots of useful settings that can NOT be derived from the .pom file. What if fellow IntelliJ users want to share those settings? I know that .ipr files ARE designed to be versioned (see this thread for example). I wish I had an actual answer, but I haven't yet found a good practice on this matter.

mcherm
  • 23,999
  • 10
  • 44
  • 50
  • 1
    I am using the .idea directory layout which is supposed to be more VC-friendly. Still there is a lot of changes each time which pollutes the VC history if you are not careful. One possibility I want to try is to put .idea under svn:ignore but check it in manually on demand from time to time. Same goes for .classpath and .project Eclipse files. – Sasha O Dec 07 '09 at 18:18
  • This seems to be more of a question than an answer. I think this belongs as a comment to another answer. (Sorry, I know saying this makes me a bit like the "Stack Overflow Procedural Police" but the system works really well if people use the system properly. So go vote down the answer you think is wrong and vote up the ones you like. I think Alexei got this question more right than the others, so I voted him up and the others down.) – David J. Sep 17 '11 at 00:38
3

My opinion is that we should keep any IDE specific files out of Version Control. The idea is that we should keep as much as possible information in IDE independent form like Maven pom files and so on. All critical project settings can be kept there. And having all major project settings kept in pom file I don't see any serious reason to check in not only IDEA project configuration but any other IDE specific configuration. Additionally, .idea folder style project configuration really pollutes changeset logs. And we still want to keep IDEA project settings in version control, we can at least store them in single .ipr file format.

Maksym Govorischev
  • 764
  • 2
  • 5
  • 12
  • If a goal is to help a development team use a shared IDE configuration, putting most of the .idea files into source control IS a _great_ idea. I see that alexi.vidmich understands this in his answer. – David J. Sep 17 '11 at 00:32
  • I can partially agree with this, but it's correct only for the configuration that doesn't involve any underlying system details like absolute paths, runtime environments etc. – Maksym Govorischev Oct 25 '11 at 08:20
1

I'm late to this party, but this exact issue has been plaguing me. And I was just inspired with what I believe could work, at least with our source control system.

The IntelliJ files do not have to be stored "together" with the authoritative pom.xml and the source. The version control history is not "polluted" if those non-source related changes are recorded to a different place in the source tree.

So I will try moving the IntelliJ files to a parallel place in the version control system, use a simple file/directory mapping to reunify source and project files on developer machine, and monitor changes in the version control system that are purely to files that affect the build.

baliset
  • 11
  • 1