How to layout folders locally and in SVN when using eclipse

Question

I've been working with eclipse and SVN for many years in teams from a single developer up to 12 and I always was the one to setup our folder structure. I managed to get it working somehow, but I feel that my folder layout is far from optimal. It's hard to tell what my typical folder layout looked like, because it looked very different each time.

I'm just starting another big project now, and I want to do it the professional way this time.

Facts about the project

Those are the facts right now:

• All developers will work with Eclipse
• Some will be using Subclipse to integrate SVN into Eclipse, others will use external clients like Tortoise SVN or svnX
• we're developing on Windows and Mac OS
• we're using ant to automate building and junit testing
• there will be multiple interrelated projects:
  • a library written in pure java, so it runs on all known java platforms
  • several applications for several java plattforms (J2SE, J2ME, android...). All those applications depend on the library mentioned before

What to do with .project?

I'm alway unsure wether to commit those files generated by eclipse (like ''.project'' and ''.classpath''). In prior projects, sometimes we put them into the SVN, sometimes we didn't, and both approaches had ther pros and cons. Once, we even committed the whole workspace, but that seemed to be a bad idea.

One key concept that I'm certainly missing is how Eclipse handles its workspace. By default, the whole project lies inside the workspace-folder, but there can be projects that are external, which are linked in some magic manner I just don't understand.

Possible folder layouts

I'm unsure how to layout the project locally and on the repository. I think there are three possibilities:

• the workspace is a subfolder of my local working copy (like c:\code\myWorkingCopies\projectXyz\trunk\workspace)
• my workspace IS my working copy (I use c:\code\myWorkingCopies\projectXyz\trunk\ as workspace)
• My workspace is somewhere (c:\code\workspace) and my working copy somewhere else (c:\code\myWorkingCopies\projectXyz\trunk) and I have those external projects
• any other ideas?

What kind of answer am I looking for?

A dummy folder structure, maybe something like that (do I just answer my own question?):

• trunk
  • projects
    • projectA
    • projectB

Along with a hint what to checkout where, like that:

• checkout trunk/projects to c:\code...)

And some guidlines like

• never upload files of type x,y,z...

Answer 1

Workspaces and repositories shouldn't be related.

The workspace is really just where Eclipse stores a bunch of settings. Project files can (and usually do) live in the workspace, but as you know, they can be imported from an external source--the import is just a logical link.

You can create as many workspaces as you want for specific purposes; you could even import projects in one workspace into another if you had reason to do so.

The SVN layout should be separate from how your workspace is defined. They may end up looking similar, but that shouldn't imply that they're actually the same. I'd recommend each Eclipse project have its own SVN project, so that instead of having

• http://myrepo
  • myworkspace
    • trunk
      • projectA
      • projectB
    • tags
    • branches

you have

• http://myrepo
  • projectA
    • trunk
    • tags
    • branches
  • projectB
    • trunk
    • tags
    • branches

What this does for you is give you the flexibility to lay out your workspace completely separate from how your repository is structured. You'll be able to check out individual projects into the workspace without having to checkout the entire codebase. You'll be able to have projects checked out on development branches while others are on the trunk, you can revert changes to one project while leaving another alone and so forth.

The last question about which artifacts to check into SVN is a matter of taste. I'd recommend checking in whatever artifacts are universal across the development team. If Eclipse is the standard IDE, go ahead and check in the .project and .classpath files so that a new developer will be able to checkout and build immediately. If certain plugins are universal and have config files of their own, go ahead and check those in as well. On the other hand, anything that isn't shared across the dev team should be left out of the repository.

Hope this helps.

---

EDIT

Further experience has taught me that the only things that should go into source control are the actual source files. Configuration and setup files should be regenerated by the developer when setting up a new project.