Which Eclipse files belong under version control?

Which Eclipse files is it appropriate to put under source control, aside from the sources obviously?

In my project, specifically, I'm wondering about:

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

If there are any of these for which it depends, please explain your guidelines.

Solution 1:

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)

Solution 2:

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.

Solution 3:

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.