Will my .project file cause problems in other peoples workspaces?

I share a project with other team-members over SVN. Now I am using the SpringIDE-Plugin in my Eclipse which adds a <buildCommand>-Element to my .project file, which is also under version control. None of my team members does use the SpringIDE.

So my question is: If I commit the .project-f开发者_运维技巧ile, could my colleagues workspace break after the next update?

Thanks

---

I don't know for sure if it'd break, but it can certainly cause conflicts/confusion.

My policy is to always exclude client-specific IDE config from source control, which means .project files get globally added to svn:ignore (or .gitignore) and not committed.

An example of a bad constraint that a shared .project has is that you're forced to use the same project name.
I currently have three Eclipse projects in the same workspace, referring to the same SVN project (different branches), and using my own naming convention to differentiate them.

---

I don't know the answer but that should be easy to test in your environment. Just try to use your .project file on one of your teammate's machine.

If it breaks the workspace when not using the SpringIDE plugin, the following rule of thumb will of course apply: "never check in files that break others environments".

Personally, I don't like to check in IDE specific files like Eclipse's .project or .classpath as I generate them (I use maven).

---

In my experience, when a buildCommand fails because it is missing a plugin, the rest of the build is not affected, but it does produce a potentially annoying error message every time it fails.