[Solved]-How to layout folders locally and in SVN when using eclipse-eclipse

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.

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 and Creating Linked Resources

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.

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.

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.

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.