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!
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...
5 comments:
There's one very big killer reason AGAINST keeping .classpath file in version control: javadoc and source file attachments if it's hosted locally (usually linked to a maven repo or hosted in source control).
These two paths are expanded to full filesystem paths and unless everyone is required to keep the projects and potentially maven repo at the same filepath the file is screwed.
PS. These comment captchas drive me crazy.. Had to rewrite this comment just because got it wrong... Fastest fix could be moving comments to disqus ;-)
.. and I did log in with my google account, yet still somehow blogger thought I'm "Unknown". Should be fine for next comments, had to edit profile. Anyways, I'm AhtiK.
Thx, Ahti :)
Indeed, I was thinking about moving the comments to disqus.
I've only encountered 1 type of IDE file I would consider checking in, only if all the team would agree upon it, and that's IntelliJ's .iml files. These files actually contain useful information for project setup in a relative way, if IntelliJ is setup correctly (for example, configure Maven to use the $MODULE_DIR$, and not a absolute path). But even those end up in the .gitignore file :-)
For all other files, I've never seen a use case where I would EVER consider checking in those files. Not that I've not worked on projects where they didn't do that, oh no: I even migrated projects like that to newer versions of IDE's. Fun fun fun! :-(
But there is no reason whatsoever that you would ever check in the Eclipse setup files. If you use Eclipse, and you want people to setup their workspace fast and in the same way, use the Team Project Set you can export your project to -> that's what it's bloody there for! For IntelliJ: I'd either check in the iml files (as stated), or I would just have IntelliJ figure it out for me ...
The way I see it: people who check in those files, don't have a good grasp on the tools they're using, and don't see the damage they potentially do when checking in .classpath or .project files. Or even .iml files, without any discussion on how to set them up.
P.S. I have no professional experience with NetBeans and VCS, so I can't comment on that one.
I think there is one gap with standards. Not exists something universal multi IDE's config which can provide common information not related to particular IDE or advanced editor. Because really useful have coding standard formation, path and server configs for run project just after git pull.
Post a Comment