posted this on March 19, 2013, 05:03
If you decide to share IDE project files with other developers, follow these guidelines:
This format is used by all the recent IDE versions by default. Here is what you need to share:
Be careful about sharing the following:
You may consider not to share the following:
What about .idea/libraries?
Should I store them in the source control repository?
There are many *.xml that change frequently.
David Perez, it would depend on the project you are using. If the project is Maven or Gradle based and these library files are generated automatically on import, you can exclude them from the version control. When the libraries are configured manually by the user, they should be shared.
Thanks for the very quick and clarifying reply. In my case they are managed by Maven and SBT, so I can remove them.
This is so wrong... A whole lot of files inside .idea store user-specific settings, depending on a variety of different things like the set of installed plugins. Also, in practice, not all project settings can be shared among all developers. (My personal favorite -- spell checking. I always turn it off as it is rather distracting, the negative is that it's a change inside .idea that I have to deal with.)
Erdinc, it's not possible. Your use case and the feature request is welcome at http://youtrack.jetbrains.com/issues/IDEA. Please describe what configuration files are different between the users and how you want to share them.
Here's my current issue with checking in *.iml: http://youtrack.jetbrains.com/issue/RUBY-14941
if dataSources.xml is supposed to be excluded, should sqlDataSources.xml also be excluded?
Actually I don't think you can ignore dataSources.xml, because if you have configured some JPA/ORM persistence checking in your project, then the .iml file will contain those references, which appear to reference structures in sqlDataSources.xml which reference structures in dataSources.xml. Does that sound right?
I am trying to set up a shared dev environment for MediaWiki / Vagrant as described in https://www.mediawiki.org/wiki/MediaWiki-Vagrant
There are a number of questions that are unclear when doing it for the latest PhpStorm EAP (138.84):
Here's a pretty well thought-out .gitignore for you to try:
Thanks Raveren, a very useful .gitignore example.
Novice question here: if I've got no plugins (not using Maven or Gradle or anything) and simply using intellij and GitHub to develop with a team of others that may or may not be using intellij as well (they might be using Eclipse, NetBeans, or some other IDE) how should I be configuring my .gitignore?
Should I simply be ignoring everything generated by intellij (such as the entire .idea/)?
Short answer, it won't hurt to add the .idea folder to git and there could be benefits sooner or later.
misc.xml is killing me. We check our intellij project into source control. There are some shared config options in there for plugnins... like an eclipse code EcliipseCodeFormatter, CheckstyleConfigurable, FindBugsConfigurable.... all good shared thingies... but this dang value also keeps getting added:
<option name="state" value="ssh://email@example.com:29418/mygitproject" /> </component>
it makes me sad... its clearly 'per developer' information..
Is it possible to share version controlled configuration between different JetBrains products - IDEA, AndroidStudio, etc. ? I want to include it in my dotfiles.
I can understand not checking in user-specific information from workspace.xml, but having the application target configurations as something that is shared among team members would be very useful. This is a constant source of problems when sharing project code among several team members.
Almost all the benefits you state are provided by using Maven as the build system. IDEA will import a Maven POM, often completely seamlessly and without intervention. Why duplicate that information in project files.Netbeans also integrates seamlessly with the Maven POM.The only IDE project files I ever see in VCS are for Eclipse. I think this speaks more of the failings of Eclipse than it does any merit in versioning IDE project files.
Send from: VigRx Plus
Would it make sense to have a separate directory for files that shouldn't be shared (local)? Maybe something like:
.idea <-- don't ignore.idea/local <-- add to .gitignoreso things like workspace.xml could go into .idea/local
I like this idea.
As different people may have different versions of IDEA, and if your project imports cleanly from SBT, Maven or Gradle, another approach is not to have any.idea/ files under version control.
My teammate and I keep conflicting over the "Project Interpreter" setting in <project_name>.iml. It seems to me like this should be a local setting. The issue is that he is installing the necessary libraries on his laptop, and I'm using a VirutalEnv.
Is there some way to prevent this setting from being in conflict?
For the Python interpreter you have to rename it when adding so that it's stored in the project under the same name for all the users, the actual location would be stored locally and you will not have any conflicts, same as for JDK.
Serge, thanks for the quick response. I'm not sure I follow though. Here is the conflict:
me: <orderEntry type="jdk" jdkName="Python 2.6.8 virtualenv at ~/dev/cti-virtualenv" jdkType="Python SDK" />
him: <orderEntry type="inheritedJdk" />
"Python 2.6.8 virtualenv at ~/dev/cti-virtualenv" can be renamed to "Python 2.6" in the settings for both machines.
Hmm... I'll try it, but I don't really see how its going to change things. All that did was change the line for me, when he loads it, I think it complains that the path isn't found (because it isn't).
It shouldn't be the case that we have to share this setting. Also, this line is always in conflict from misc.xml:
me (now renamed my virtualenv): <component name="ProjectRootManager" version="2" project-jdk-name="Eds CTI Python 2.6.8 VirtualEnv" project-jdk-type="Python SDK" />
him: <component name="ProjectRootManager" version="2" project-jdk-name="Python 2.6.7 virtualenv at ~/work/cti/envs/cti" project-jdk-type="Python SDK" />
It seems like the design is that all team members have to locate their VirtualEnv in the same place and give it the same name?
Support Software by Zendesk