a quick hack that i've used in the past: have
/users/<username>/eclipse directories and have folks store their own
stuff there that they needed and symlink /.classpath, /.project and so
on to the files in the individual user directory (or simply copy it
over by hand).

in addition, provide a common /users/template/eclipse/project.template
and so on that people can copy and use as a basis.

then add /.* to ignore list.

you can replace a template with a maven target that can produce a
basic set of files using its IDE integration.

finally, use variables as much as possible in the IDE config files (as
opposed to hardcoded paths).

but of course it all depends on the project, its complexity, people
involved, ides used, etc.

-a

On Sat, Jan 3, 2009 at 1:26 PM, Steve Berczuk <steve.berczuk@...> wrote:
> What are people's thoughts on how to treat IDE configuration files, as
> compared to build script files in terms of sharing and version
> management?
>
> Here's a concrete example to motivate the discussion:
> - A team is using Maven as their primary build tool.
> - Developers on the team as using various IDE, say IDEA, and Eclipse.
> (The example is Java centric, but comments from those not in the Java
> world would be helpful too :) )
>
> Should IDE project files be treated as primary artifacts, version
> controlled and shared, or are they derived artifacts?
> Some of the discussion points that come up are:
> - It is possible to generate Eclipse and Idea files from Maven POMS.
> And Both IDEs have the ability to keep their project files in synch
> with the Maven POM files, so all dependency information can be stored
> in the Maven Build.
> - The maven build is the build of record.
> - The IDEs can provide for enhanced warnings and errors for coding style
> issues.
> - It is possible to add support for errors and warnings as part of the
> build.
>
> How do your projects treat IDE files? Do you version them like build
> scripts and treat IDE warnings and errors the same way you treat
> "Build" warnings and errors?
>
> (I have some thoughts, but would like to not say too much until there
> is a discussion so as not to bias anyone :)) )
>
> Steve
> --
> Steve Berczuk | steve@... | http://www.berczuk.com
> SCM Patterns: Effective Teamwork, Practical Integration
> www.scmpatterns.com
>
>