Using Subversion Source Code Control With Eclipse Workspaces and Projects

Questions:

Commit the whole workspace or not?
Commit eclipse generated (like .project & .classpath) - pros and cons

Workspaces and repositories should not be related. One project may live in multiple workspaces.

Recommendation:

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.

Alternative view: Flexibility comes at a price; my experience with this naming scheme leads me to believe that the cost in manual work and potential for mistakes simply isn't worth the trouble. Since SVN only actually copies files on-demand, I prefer to branch out my entire workspace rather than individual projects.

Another suggestion:

I usually recommend checking-in everything in the project except what is generated (such as the build output folder, what you seem to call "bin"). That includes the .project, .classpath, and .settings files. As for moving between multiple machines, the best way is of course to always check in to source control before moving. Trying to manually move files around is troublesome and I almost guarantee that eventually you will lose some work because of a mistake.

Example of project organization - http://www.javahotchocolate.com/tutorials/use-eclipse.html

You do not commit to Subversion, for example, any .class files or JARs built dynamically as part of a build. However, you would (you have some latitude in this, but here's how I do it) commit JARs from one project ordinarily expected in another. In other words, if you have an ant script that builds and copies JARs from project A to project B's WEB-INF/lib folder, for example, you would commit those in project B (but probably not try to commit the JAR as built in project A in project A).
Similarly, you should commit libraries from third parties like Apache, Sun, etc. that your projects need to build.

Best Practices
I've been using the plugin for a few years now and I find the following to be very helpful.

1. Commit as often as possible. Don't over think it. Just commit as much as you can. I find that there are only benefits and no downsides to committing often.
2. Read up on branching and tagging and come up with a strategy. This is an excellent guide on how to make the best use of branching to keep track of bug fixes and enhancements: http://blog.kabisa.nl/2008/01/10/subversion-release-management/
3. Add all projects to version control regardless of complexity. I have a web interface to my svn repository and I often need to refer to some code I wrote inside a simple demo eclipse project.

Sources: