Checking in an Eclipse project into SVN

Question

I want to checkin a Dynamic Web Project I created in eclipse into svn. Can someone tell me which files I have to check in and which one I should not? The idea is to be able to check out the project using the New Project Wizard so that I can create the Dynamic Web Project again. More specifically here are the files/directories I have in the project --

• src
• WebContent
• build
• dist
• build.xml
• .project
• .classpath
• .settings/

The build directory is not supposed to checked in obviously. What about the other ones? I am guessing all the . files should not be checked in either. Can some one verify this? What is this dist directory and the .settings directory?

Also where does eclipse store the Server information (tomcat)? I don't want to check it in either.

EDIT:

I initially checked in all of the above except the build directory of course. When I checked out the project from inside Eclipse it did not prompt me to create a new project since the .project is there but Eclipse was creating a JavaEE project or something instead of the Dynamic Web Project. Did anyone else run into this behavior?

** EDIT 2 **

Found it! Turns out I should not check in the following --

• .project
• .settings/
• .classpath

Once these 3 are removed the New project Wizard works as expected and everything is fine.

Answer 1

If you check in .classpath/.project/.settings you make your project Eclipse-specific. What about developers who work with Netbeans or IntelliJ ? IMO it is cleaner to keep your project IDE-independent and easy to set up.

I usually go for a Maven build. The pom.xml specifies all the required dependencies and mvn eclipse:eclipse generates the .classpath/.project files for you.

The .settings directory contains local settings (like which Java version you want to use). IMO it is not useful to check this in. You can enforce Java version compliance via the Maven2 pom.

Finally, for your next project, my protip is to svn-ignore the files or directories you don't want in SVN before your first commit. In a Maven2 setup that would be .settings .classpath .project target (the default output directory of Maven2) and any other generated stuff (log files, gfembed directories, etc). In your case you would ignore build and dist instead of target .

You can svn-ignore files or directories with RIGHT_MOUSE->Team->'Add to svn:ignore' (I use the Subclipse plugin). Ignore instructions are stored as svn-properties on the parent directory. The properties on a directory can be viewed by RIGHT_MOUSE->Team->Show properties . You can also edit the properties directly there by clicking on the value field. Make sure there is an end of line after each property.

Now that you have already committed and then removed these files, ignoring is not going to work anymore in my experience. Somehow I have never managed to successfully ignore generated files which have ever been checked into the SVN repository; they are like zombies, always coming back from the dead. Maybe by deleting their entries physically in the SVN repo this can be achieved, but I've never done it.

Answer 2

In our case, we have checked in all you mentioned in the list except, .settings/.

With .classpath and .project checked in, users can quickly check out the project and fire up Eclipse on a new computer and just start working on it; the alternative being to configure the project manually and adding in all the jar dependencies painstakingly (if you use ant). Many open source projects do this.

Read this , there are some really good points to ponder about.

Answer 3

Good Question... Many of us are in a dilemma on whether we want to check in IDE related files or not. I normally go for checking in .classpath for eclipse and I use eclipse variables to make sure that team needs to just change the variable value and it works. We also check in .project so that team need not to create new project in their workspace.

Answer 4

I would omit the .project, .settings/, dist, and build.

The .classpath can be left in if you use variables instead of hardcoded paths. This is useful so you don't have to rebuild your classpath every time you check out the project.