When working with Eclipse, should I add the workspace to the source control?

Question

I am the only developer on this project.

Answer 1

I would commit only the project(s) you are working on, as well as .classpath and .project files, and not the whole workspace itself.

Answer 2

I wouldn't commit the whole workspace. But it is worth exporting platform settings and checking them into source control (probably in a separate SCM project as they don't really belong to any individual project) if you've made several changes in case you need to import them into a new workspace.

Examples of these files are those settings for:

• Java->Code Style->Formatter
• Java->Code Style->Clean Up
• Java->Code Style->Code Templates
• General->Editors-Text Editors-Spelling-Dictionary
• Any other preferences you've made extensive changes to that support import/export

You should check in the primary sources/resources for the project. As others have noted, for a typical project this includes the .project and .classpath files.

Depending on the type of project, I'd add the .settings folder from the project. This folder contains project-specific settings that override the platform preferences, and other project-specific settings. If those are essential to your project then I would add them.

Answer 3

Even if you are the only developer, avoid committing the .settings directory. You could switch to another version of Eclipse, or another installation with a different set of plugins, and when you checkout projects in the second installation the .settings directory will be different. Also the .metadata directory is bound to vary.

That said, attempt to use Maven so that the Eclipse .project and .classpath files can be generated without requiring them to be checked in.

Answer 4

I've played with the idea (with Subversion) of having a "MyProject_Eclipseproj" folder that only contains the the Eclipse project files and directories, with an svn:externals prop that pulls in all the "MyProject" files/directories.

So, the layout would be:

/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath

The MyProject folder would be pure code, no eclipse contaimination. The MyProject_Eclipse_Ver would contain Eclipse specific files, and pointers to pull in the code folders. You could also have specific folders for different Eclipse versions so each developer wouldn't be forced to upgrade if something changed in the .settings or .project file between versions.

Answer 5

I would not add the complete workspace, but I would add the .classpath and .project files (as well as the source, of course) so that you can recreate the project if needbe.

Answer 6

No.

Files that are generated by the IDE or by a build process (binary files, documentation produced by a generator) should not be checked into source control. The only files that should be checked in are your source files and external libraries that your source files utilize.

You might also be interested in the answers to this question: What should NOT be under source control?