Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

which eclipse project/workspace files should be added to source control?

I want to share an eclipse project with the rest of my team through SVN. Which files should I add to subversion? In the workspace, there are many files which IMHO are not supposed to be on source control - they are a few megabytes in size.

When adding just the project, another user who checks out the code still has to import the project into the workspace.

Edit: maybe the correct question here, is how can I share my eclipse workspace using subversion?

like image 504
noamtm Avatar asked Sep 02 '09 10:09

noamtm


People also ask

What should be the workspace for Eclipse?

The workspace is a directory on the disk where the Eclipse platform and all the installed plug-ins store preferences, configurations and temporary information. Subsequent Eclipse invocations will use this storage to restore the previous state. As the name suggests, it is your "space of work".

Where are Eclipse workspaces stored?

An Eclipse workspace is a folder on the disk where the project and application files are stored. The default location for an Eclipse workspace is in the user's area (for example, c:\users\ username \).


3 Answers

With Eclipse, you always have to import a project - there is no other way to do it - Eclipse won't detect projects if you just switch workspaces unless you've created/imported the project in that workspace before.

You will need at a minimum:

  • .project
  • .classpath

Personally I also add the settings folder, but its up to you:

  • .settings

Then other users choose Import project and select the .project file.

like image 90
Nosrama Avatar answered Sep 20 '22 12:09

Nosrama


I would say "none of them" - I find it's easier to just store the code in subversion, then create a new project in Eclipse using the "Checkout Projects from SVN" wizard

If you've got a workspace which isn't currently under subversion control, then the easiest method would be to create a copy of it, trim all the unwanted files, then import that into subversion. Then you can create a new workspace using the wizard to link it with SVN.

like image 45
Paul Dixon Avatar answered Sep 21 '22 12:09

Paul Dixon


For the workspace, consider using a 'team project set'. You can create one through the export action. This produces a file which you can email to your colleagues who then import it and all the shared projects will be checked out.

For each project it depends on what type of project it is. If it's a Java project:

  • Exclude the JDT output directory (default is bin/, sometimes out/ is used)
  • Exclude any build artifacts that may have been generated (including those in your source folders)
  • Include .classpath and .project
  • Include your source folders
  • Include your dependencies (if you are not using an external dependency management app like maven)
  • Optionally include your JDT prefs file, depending on whether you want people to share code templates, formatting conventions etc
  • Optionally include any .launch files (saved launch configurations) but be careful as these may have platform specific entries and so won't work on different computers

In general, if a resource is a derivative of another then it should be excluded.

like image 22
Dan Gravell Avatar answered Sep 19 '22 12:09

Dan Gravell