On a project I am working on in IntelliJ, the IDE generates a bunch of files of type .iml. When looking at svn st in my project directory, all these files are shown. Not wanting to commit all of these IDE related files to my repository, I chose to ignore this file type (as outlined here):
svn propset svn:ignore "*.iml" .
However, now my project is showing all of my sub-directories as modified when I check subversion status (svn st). I don't want to look through a massive list of modifications when preparing to commit changes, but I feel hesitant to commit all these modified directories.
First question: Is ignoring the .iml files a good practice when committing IntelliJ projects?
Second question: Is it safe to commit all my project directories that have been modified as a result of ignoring the .iml files?
Update: I decided to roll back the ignore on .iml files, as the list of .iml files is shorter than the list of modified directories I would have to commit. I still don't feel that I have found a clear best practice for this. Anyone who regularly codes with IntelliJ IDE have a good solution?
Question 1: Are those .iml files generated automatically from other items that are versioned, or specific to your user/workstation? If so then yes, you should not version those (and ignoring will help you with that).
Question 2: If all you're committing is the property changes for the directories, then yes. If you have changed files that you're also committing, will those break the build or otherwise violate any rules your dev process has for what should & shouldn't be committed (and when)?
My rule of thumb is that each commit should be associated with only one change. So in this case, I would commit just the svn:ignore property changes, and if I had other uncommitted changes I'd commit them separately. Reason being that if I have to roll back a change later, I don't lose change A because change B was in the same commit, even though they're unrelated.