I am the only developer on this project.
views:
338answers:
6
+8
A:
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
2009-09-15 19:19:25
+1. still, those are of project scope, not workspace. how about .metadata and other .xxxx directories directly in the workspace folder?
van
2009-09-15 19:42:00
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
2009-09-15 19:47:37
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ý
2009-09-15 19:54:24
+2
A:
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?
Thomas Owens
2009-09-15 19:20:16
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
2009-09-15 19:40:58
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
2009-09-15 19:42:48
van: The files that you check in are independent of editor, version control system, programming language...
Thomas Owens
2009-09-15 19:49:31
"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ý
2009-09-15 19:57:26
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
2009-09-15 19:59:27
+2
A:
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
2009-09-15 19:21:35
+1: @nstehr. would you not add for example "org.eclipse.core.resources.prefs" file under ".settings" folder of the project? why?
van
2009-09-15 19:43:30
+2
A:
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
2009-09-15 19:31:15
+1
A:
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
2009-09-15 19:32:50
+5
A:
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
2009-09-15 19:38:05