0

.project files contain references to the project natures used in the project.

These project natures are dependent on the plugins installed on the local developers machine.

So, should this file be excluded from SVN?

Will nautures unknown to other developers cause problems?

Thanks

Michael W
  • 3,515
  • 8
  • 39
  • 62
  • 1
    Have you already looked at [this question](http://stackoverflow.com/q/1366953/1374267) and at [this one](http://stackoverflow.com/q/1591756/1374267)? – Yannick Blondeau Jul 31 '12 at 12:24

2 Answers2

1

I never commit those (esp .project) and always vote for them to be svn:ignore'd. Maybe I'm wrong but I only commit code to SVN and then make a new project by checking out from SVN.

Every time I checked out a project which had those files commited literally BROKE my project. But then again maybe thats just my coworkers... By breaking i mean converting these

src/com.package.name1
src/com.package.name2
src/com.pack.name1
src/com.pack.name2

to these

src/
src/com
src/com/package
src/com/package/name1
src/com/package/name2
src/pack
src/pack/name1
src/pack/name2

and other sorts of unnecessary irritations... like them not being recognized as packages anymore but as folders. One of those things that makes you have to run eclipse -clean or delete/reimport a project or waste time on eclipse stuff you don't wanna waste time on.

Shark
  • 6,513
  • 3
  • 28
  • 50
1

It depends on your situation.

Indications for putting them under version control:

  • you are talking about a team in a company context. You should be able to enforce a common developer environment, unless you also have an organizational issue.
  • everyone is using Eclipse
  • you want to make it more easy for newbies to just check out the project as such from SVN (without recreating it as a new project)

Indications for not putting them under version control:

  • the people (or IDEs) working on the project are very different (like in public open source projects)
  • you want to also use the project on an integration server like Hudson/Jenkins. You need to use Maven or some other standardized artifact lifecycle management tool outside Eclipse then.

The best solution: Use Maven to describe your dependencies and build process completely independent of Eclipse. Afterwards use Tycho to "act as a broker" between the Maven and the Eclipse world. That way you know exactly what to put under version control and everyone will produce exactly the same builds (independent of what IDE he uses or which plugins are installed).

Bananeweizen
  • 21,797
  • 8
  • 68
  • 88
  • 1
    I would accept your answer in its part that it is best to use Maven (or another dependency management tool), but in the part that it is applicable to commit `.project` and `.settings/`since those files/folders contain **project and user** specific settings. Usually these files should be added to svn:ignore. – Borislav Sabev Aug 01 '12 at 05:50
  • 1
    @BorislavSabev: I did not write anything about the settings folder, only about the .project file as asked in the question. And that one has no user specific settings. I agree with you on the settings folder, but some of the settings files are still more useful if under version control in non Maven team based projects. For instance the settings for Java compiler, errors and warnings, formatter and save actions are always shared in our team to avoid that people introduce whitespace changes when committing and that everyone creates similar builds. – Bananeweizen Aug 02 '12 at 05:34