11

I am the only developer on this project.

AngryHacker
  • 59,598
  • 102
  • 325
  • 594
  • 2
    See also http://stackoverflow.com/questions/116121/do-you-keep-your-project-files-under-version-control/119377#119377 – VonC Sep 15 '09 at 20:07

6 Answers6

14

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.

akf
  • 38,619
  • 8
  • 86
  • 96
  • +1. still, those are of project scope, not workspace. how about .metadata and other .xxxx directories directly in the workspace folder? – van Sep 15 '09 at 19:42
  • 2
    I completely dissagree with the idea that your .classpath and .project files should be added to version control. They are specific to your workspace. If someone else tries to check out your project and they have their eclipse set up differently (different plugins, settings, etc) it can cause problems. They can be easily recreated when checking out the project, so even if there is only one person on the project (right now) there is no need to store them. – Ryan Guill Sep 15 '09 at 19:47
  • 1
    What so workspace-specific about .classpath? I can understand .project part, although I think it's much easier for involved people to have it in VCS, but .classpath? It's easy to make it workspace-independent (and it usually is). – Peter Štibraný Sep 15 '09 at 19:54
9

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.

Rich Seller
  • 83,208
  • 23
  • 172
  • 177
  • +1 to you, Sir: basically what I was saying in http://stackoverflow.com/questions/116121/do-you-keep-your-project-files-under-version-control/119377#119377 , more than a year ago ;) – VonC Sep 15 '09 at 20:07
  • uncanny - almost a year to the day. – akf Sep 15 '09 at 20:18
5

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?

Community
  • 1
  • 1
Thomas Owens
  • 114,398
  • 98
  • 311
  • 431
  • 1
    Disagree, at least some element of the project MUST be under SCM. Otherwise how do developers get project updates? There's always some project metadata that's valuable to include. – Kendall Helmstetter Gelner Sep 15 '09 at 19:40
  • 2
    What do you mean "project updates"? Also, what if I'm using a different IDE? Or a text editor (emacs? vim?) instead of an IDE? Only build scripts, source files, and dependencies should be checked in. – Thomas Owens Sep 15 '09 at 19:42
  • van: The files that you check in are independent of editor, version control system, programming language... – Thomas Owens Sep 15 '09 at 19:49
  • "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." is often not as good answer as it sounds. I am not telling that you should commit everything, but often there are artifacts which are not easy to recreate. I.e. I usually commit pdf/chm files generated from DocBook, as you need lot of different tools to recreate them. Even though it is possible, it takes time to hunt all those tools. – Peter Štibraný Sep 15 '09 at 19:57
  • 1
    Peter - I've never used DocBook, and that might be a valid exception (after all, every rule does have exceptions). However, for most things, the developers should have all of the tools required to generate them. – Thomas Owens Sep 15 '09 at 19:59
2

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

nstehr
  • 7,978
  • 2
  • 18
  • 22
  • +1: @nstehr. would you not add for example "org.eclipse.core.resources.prefs" file under ".settings" folder of the project? why? – van Sep 15 '09 at 19:43
2

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.

Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
1

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.

Trevor Harrison
  • 1,744
  • 1
  • 14
  • 20