Anton Arhipov is a Software Developer and Product Lead for JRebel, the productivity tool for Java developers. Anton’s professional interests include Java and related, programming languages and middleware. You can follow Anton on Twitter (@antonarhipov) and find him on LinkedIn (linkd.in/aarhipov). Anton has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

IDE Project Files In Version Control - Yes or No? Of Course, Not!

07.29.2012
| 4133 views |
  • submit to reddit
NB! This topic is mostly related to Java projects. The situation might be a little different in case of other technologies and IDEs.

Just recently I had some discussions with the clients who were claiming that they keep IDE project files in version control system hence they avoid any changes to those files. For reference, those are Eclipse generated .project and .classpath. From my point of view it is a bad practice by all means, however I usually prefer to collect some information on the topic before I say it loudly. So I asked from my G+ and Twitter followers, IDE project files in version control - Yes/No? Surprisingly, I've got quite a number of responses, so I decided to summarize the information as a blog post.

Basically, the answer to this question isn't binary, yes or no, but it also could be "yes, but... " or "no, if...". So there might be some argument why someone prefers one way or another.

The vast majority of the answers is "No, no, noooooooo!! Never!". And just a couple of answers were "yes" with some weak arguments of why someone should keep those files in version control.

Here are some yes answers first.


Bad stuff. Seems that the team isn't really competent with the tools. The project should be easy to setup and why on earth I should press 100500 buttons to setup a project. If this is the case, the first thing that team lead should do, is to simplify the project structure, setup and build process. No excuses there.

Yeah, yeah, I can already hear some arguments like "but we have a complex project" or "this is the way our setup is done". Bullsh*t!

OK, there is some optimization for the setup, IDE specific though. If all the team members use the same setup, it might even make sense for those who want to keep hands off the console.

Here's another one:


"Specific Eclipse plugins" - yeah! that's is actually an argument for not keeping the files in version control! Eclipse plugins usually modify .project files as they add a "nature" or any other project specific settings to the configuration. And actually, IntelliJ does the same, but (let me bash to tools a bit) IntelliJ can suggest the settings as you open a project from scratch. And with Eclipse, you have to do that manually. What if your colleague uses some awesome eclipse plugin that makes modifications to .project file, and you hate that plugin and do not want to install it, and the .project file is in version control? Here's just a simple example that you could see while exporting a project with existing project files:


This is so annoying to resolve this kind of problems. And all you want to do is just to open the project and proceed with your normal work.

Here's more:


Currently, I use IntelliJ and the rest of the team uses Eclipse. And I absolutely do not care if they put the project files into version control, because I will import it into my IDE in two clicks anyway. So the assumption that "absolutely yes, given that the team is working with the same IDEs" is wrong, and no viable argument here as well. 

However, here we have some much more interesting ideas:


Wow, this is really interesting one - "those that define formatting or source code". Indeed! In cases when you work on varions projects for different clients, the requirements and code styles might be quite different and it makes sense even to keep this kind of files in version control, so you can share it with the team and restore the code style settings if you lost them. Good point here!

However, you can probably see the vector of my post now.



So the point is, IDEs support Maven quite well, so why on earth I would need to keep the IDE settings in version control if we already have what we need: pom.xml. IntelliJ and NetBeans cope with that quite well, and Eclipse also, if you use JBoss Tools.

But what if I'm a Maven hater? (I really am). Here's an interesting conversation:


Oh sure, Gradle that is! Well, the IDE support isn't there yet. Luckily, STS provides a nice Gradle plugin for Eclipse, but the support for IntelliJ and NetBeans isn't quite there yet.

However, my claim is that Maven or Gradle isn't the prerequisite to avoid the project files in version control. The real prerequisite is the simple setup of you project and a clean structure, so that importing the project is just a couple of clicks. Then you can cope with any kind of project, even if it doesn't contain pom.xml.

And here's what most of them say about the topic:



Myself, I have tried both ways - keeping the project files in version control and not checking them in, and my take is that under no circumstances it is a good idea to check the project files in. Again, a much better solution is to keep your project structure clean and simple, which might be harder than to check the files into version control, but much more beneficial on the long run.

Thanks everyone for the input! Take care...
Published at DZone with permission of its author, Anton Arhipov. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Thomas Stroeter replied on Wed, 2012/08/01 - 9:00am

A yes or no answer seems to be a little bit to easy to me. It depends on. If you work in a homogenous infrastructure where every developer has to use the same IDE it makes sense to me, also to reuse the projects settings. The costs for configuring an IDE-project correctly are not that low. We use eclipse projects that make use of more than 30 external libraries. If you want to work properly with them, use the debugger etc, you have to configure their sourcecode and javadoc location. I'am not a maven-expert, but I think a *.pom file would not automatically deliver this information to the IDE of your choice. For an eclipse project in a homogenous IDE infrastructure it makes also sense to me to check in the code-templates, compiler warning- and compliance- settings. So I would choose an pragmatic approach and first check the benefits and the costs and then decide what should be placed under version control and what not.

Nevertheless, in my point of view there should be additionally buildfiles (ant,maven,bat,sh or what else ) to create the project via commandline or your continues integration tool that are placed under version control, too. The goal should be that an developer can easy load a project within his IDE to maintain the project and that he can easy build the projects artefacts via commandline or ci-tool.   

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.