What to Version?
Everyone reading this, we hope, has build scripts (pom.xml files if they are using Maven, build.xml if ANT, Makefiles, etc.) under version management. In the interests of efficiency, it might be suggested that IDE configurations should also be under version management. To see if this makes sense, let's think about the different types of IDE configurations: build settings and tool settings.
Build settings are, in effect, what is in the build configuration files. maintaining these for IDEs is duplication. It's better to generate them from the build. Tool settings are a reasonable thing to maintain and version if there exists the possibility for user customization of settings that don't really matter to the whole team, but which improve developer productivity. Since IDE files are often redundant in building scripts, if the IDE files are not maintained to be in sync with the build scripts, team members will learn to ignore the project files in version control. It’s good to avoid a a situation where team members ignore versioned files because they don't want their files overwritten. This defeats the purpose of versioning the files and leads to confusion. Versioned files should add value to the project.
Don't version IDE configurations, as this is related to build path issues. Use tools to keep IDE settings in sync with the build scripts and avoid any duplication. It may seem like a small amount of work, but manual effort to maintain IDE files is rarely high value. Maven provides tools to generate Idea and Eclipse configurations from POM files. Idea and Eclipse both have plugins that can work off of Maven pom files to synchronize build and IDE settings.
Tool vendors (both IDEs and script-based tools) should consider the ability to synchronize between IDEs and scripts to be a high priority as IDEs and other build tools serve complimentary purposes, and are of the most value when their configurations match as much as possible.
You can benefit by versioning configurations relating to style that can be universally used by all team members. It’s important to keep the build scripts as the source of build and dependency configuration as much as you can. Bridging The Gap between IDE and Build Tools The private build pattern gives the most concise guidance for how to ensure that a build is sync: run a build in your workspace with the same toolset that works in the integration build. A continuous integration process (running the integration build patterns) provides a backstop for when you goof. Incremental builds are fine in an IDE when you are coding, and the instant compilation that occurs after a change helps to maintain flow when coding. There can be subtle, and not so subtle, differences on the build environments, though, that range from specific compiler implementations to path configurations. This means that what works in your IDE may not work in your build and broken builds slow everyone down
As long as the contract of the integration build being successful is honored, we should not need to overly constrain how developers work.
What To Do? IDEs are a common part of a developer's tool kit. They are highly customizable, increase productivity, and help enforce coding standards. Some developers have very strong opinions about what the best one is. Every team struggles with development standards. Standards affect communication (coding standards) and execution (tool standards). Standards can help a team be more effective by eliminating discussion on matters that are less important to the end result and also by enhancing communication by establishing a common style and language.
Too many standards, or standards applied to appropriate concepts can have the effect, reduce productivity and cause the team to spend a disproportionate time coding to the standard, rather than delivering value. Let's wrap up by offering some recommendations on the questions we raised at the start of this article. We recommend: