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

I recently started using Subclipse and have a method that works for me. We're working with PHP applications, so I create a new SVN project through the Eclipse project wizard, choosing to 'Checkout Projects through SVN'. I then configure that project using the project configuration wizard and select PHP as the project type. I name the project so that in my workspace I have the project name at the top-level of the project explorer.

I never commit anything that is created specifically for Eclipse, especially since not everybody on our team uses Eclipse. That means excluding the .project files and any other Eclipse-created files.

An additional benefit of using this method is that you can have more than one repository checked out into the workspace. We work with two repository locations for our project (for specific reasons that I won't go into), so this makes it easy and convenient for me to work on both 'projects' simultaneously.

I'm sure there are other ways to do this, but this is what I have found to be the easiest way to use Subversion and Eclipse.

Answer 2

We have a similar setup (Mac, Linux, and Windows users) and our folder structure is:

• trunk
  • code
    • projectA
    • projectB

We do check in the .project, .settings, and .classpath files as well the code but NOT the workspaces. The real gotchas have to do with the build path. If you solve these there is no headache and no requirement as to which directory things need to be checked out in.

Some tips:

1. If your projects reference each other make sure they reference each other using the "Projects" tab of the build path. This will keep all references to other projects relative (../projectA rather than /opt/trunk/projectA which will break other peoples projects).
2. If you have any external libraries that you reference, create user libraries and make everyone create one with the same name. We use JBoss so we make everyone create a user library called JBoss that references the jars in their local JBoss installation. This way, it doesn't matter where your JBoss is installed, as long as you have that user library, you'll be good to go. Your project will reference the user library name, but the actual user library information is local to each user.
3. Make sure everyone knows about tips number 1 and 2. The only times things get screwed up around here is when someone forgets to make references via the Project tab instead of just linking to the jar directly.

All this works with Eclipse SVN plugins or without.

Answer 3

In both Macromedia Dreamweaver and Eclipse I've been doing the following:

Working folder: 
C:\Development\
    \ProjectA
    \ProjectB
    \ProjectC

Each project has its own repository, and each checkout is only of the /trunk/.

Note: For Eclipse, don't create a SVN Repository project, just create the "Java App" or "PHP App" project like you normally would, and use an external program to do the checkout into that folder. Eclipse will then automagically detect the .svn information and allow you to use the SVN tools, while still using the proper workspace.

Answer 4

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.

Answer 5

I use, and strongly recommend the repository structure something like:

• Projects
  • ProjectA
    • trunk
      • java
      • html
      • docs
      • conf
• Vendor
  • junit
    • current
    • 1.1
    • 1.2

On disk use a layout like:

c:\dev\
   \ProjectAtrunk\
   \ProjectBbranch4\

Working this way you're branches and tags are near your trunks and you're unlikely to depend upon the structure of the projects in your repository to reference external libraries. All references to code outside the project trunk should use externals.

All this means that you're more likely to be able to keep the maxim that checking out trunk is all you need to be able to build your project. Shared code is kept in and managed as a separate project and referenced with externals.

You're more able to view changes on a project trunk and see a complete history of your project without garbage. You're less likely to have changes to your project that aren't visible when you look at your revision history on trunk.

When releasing, make use of stable branches and svn-merge.

Answer 6

I'm having the same problems with the eclipse workspace / SVN checkout. I can get it all to work and build on my local workspace using the project reference system, but how do I capture that so everyone else on the project can check the whole project out without having to populate their personal workspace with the all the projects manually? (a solution stores this information in visual studio) For example exe project X needs static libraries Y and Z. A new user would have to manually create a workspace and add X, Y and Z (having to find out for themselves that X needs Y and Z). Adding the workspace to subversion seems like a hack way around the problem. I basicallly need a "workspace" level checkout. Its ok for Java apps because they have packages to sort this problem.

Answer 7

Ickster says "...but as you know, they can be imported from an external source--the import is just a logical link."

Actually, this is not quite true. An import performs a copy, whereas a linked resource is a link to the outside source structure. See: Linked Resources: http://help.eclipse.org/galileo/topic/org.eclipse.platform.doc.user/concepts/concepts-13.htm and Creating Linked Resources: help.eclipse.org/galileo/topic/org.eclipse.platform.doc.user/tasks/tasks-45.htm

Answer 8

does anyone know how Eclipse determines which projects are in a particular workspace? Is there a config file somewhere with this info? I have struggled (in vain) for several hours trying to figure this out.