Which Eclipse files belong under version control?

Metadata should not be managed in source control. They contain mostly data relevant to your workspace.

The only exception is the .launch XML files (launcher definition).

They are found in

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

And they should be copied into your project directory: When your project is refreshed, those configurations will be displayed in the "Run configuration" dialog.

That way, those launch parameter files can be also managed into the SCM.

(Warning: Do uncheck the option "Delete configurations when associated resource is deleted" in the Run/Launching/Launch Configuration preference panel: It is common to soft-delete a project in order to import it back again - to force a reinitialization of the eclipse metadata. But this option, if checked, will remove your detailed launch parameters!)

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

should be in your SCM (especially .project and .classpath according to the Eclipse documentation).

The goal is that anyone can checkout/update his/her SCM workspace and import the Eclipse project into the Eclipse workspace.

For that, you want to use only relative paths in your .classpath, using linked resources.

Note: it is better if project-dir refers to an "external" project directory, not a directory created under the eclipse workspace. That way, the two notions (eclipse workspace vs. SCM workspace) are clearly separated.

As ipsquiggle mentions in the comment, and as I have alluded to in an old answer, you can actually save the launching configuration as shared file directly in your project directory. All launching configuration can then be versioned like the other project files.

(From the blog post Tip: Creating and Sharing Launch Configurations from KD)

I am currently working on a project where we have the .project and .cproject files under source control. The idea was that settings related to library paths and link directives would propagate across the team.

In practice it hasn't worked very well, merges almost always come back in a conflicted state which need to be deconflicted outside of eclipse and then the project closed and reopened for the changes to take effect.

I wouldn't recommend keeping them in source control.

It's worth nothing that CDT configuration files are not source-control-friendly. There's a bug filed for .cproject files changing very frequently and causing conflicts, see Sharing cdt-project files in repository always causes conflicts.

Some projects, like those using Maven, like to generate the .project files based on POMs.

That said, other than that - .metadata should NOT be in source control. Your project will have to make a determination about whether projectdir/.settings does, based on how you plan to manage standards and such. If you can honestly trust your developers to set up their environment based on the standard, and you don't have to customize anything special for any project, then you don't need to put them in. Me, I recommend configuring every project specifically. This allows devs to work on multiple projects' stuff in the same workspace without having to change default settings back and forth, and it makes the settings very explicit, overriding whatever their default settings are to match the project's standards.

Only difficult part is making sure they all stay in sync. But in most cases you can copy the .settings files from project to project. If there are any you specifically don't want in source control, do the equivalent of setting svn:ignore for them, if your SCM supports it.

I'd say none of them. They most likely contain information that is relevant only to your workstation (I'm thinking about paths for libraries and all). Also what if someone in your team is not using Eclipse?

I haven't tried to put anything in .metadata under version control, but I'm using version control for these files for ten years now:

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

The main reason is that Eclipse sometimes damages those files. Without version control, you will get weird and hard to track errors. With version control, you can immediately see "Why is it trying to deploy test classes???" or "Why is Maven and Eclipse using the same classpath?" (leading to https://bugs.eclipse.org/bugs/show_bug.cgi?id=430605).

With version control, you can see when it happens and easily go back to a working set of config files.

If you use m2e: You can import the project now with the fast "Import existing project" instead of the slow "Import Maven project".

The drawback of this approach is that Eclipse seems to randomly change some of those files. Most plugins keep them stable but some use HashMap instead of, say, LinkedHashMap so the order of elements changes all the time. This means there is an additional step when you commit: Check for any modified settings and handle them, first.

It also means that the whole team has to agree on some standards: Like which warnings should be enabled. It's interesting that many people see this as a additional problem - as if they weren't working together.

In my experience, it takes a couple of weeks until those files stabilize. Partly because you gradually learn how to tweak Eclipse, partly because people learn what not to touch. You can think of this as lost time or time spent to improve the quality of your work environment (like keeping your desk uncluttered).

There is a bonus advantage of the "Commit settings first": It gets people to commit more often and in smaller pieces (i.e. more like "one thought at a time" instead of "on feature at a time plus a thousand of other, unrelated things that I just happened to stumble upton ... what was I working on again?").

As a seasoned developer, I've come to prefer the "small commits" way of working; it's just easier to stay on track and you tend to sort your thoughts and changes into smaller, more manageable steps. This helps to reduce the level of complexity. Everyone can juggle with one ball, no one can juggle with 20.

PS: For certain setting files, I have unit tests to make sure known errors don't creep in like the "trying to deploy tests" in WTP. That helps in the initial phase "commit everything, I'm too busy" phase.