Comprobando un proyecto de Eclipse en SVN

Quiero registrar un proyecto web dynamic que creé en eclipse en svn. ¿Puede alguien decirme qué files debo registrar y cuál no debería? La idea es poder verificar el proyecto usando el asistente de proyecto nuevo para que pueda crear el proyecto web dynamic nuevamente. Más específicamente aquí están los files / directorys que tengo en el proyecto –

  • src
  • Contenido web
  • build
  • dist
  • build.xml
  • .proyecto
  • .classpath
  • .settings /

No se supone que el directory de compilation se haya registrado obviamente. ¿Qué hay de los otros? Estoy adivinando todo el los files tampoco deben estar marcados. ¿Puede alguien verificar esto? ¿Qué es este directory dist y el directory .settings?

¿También dónde eclipse almacena la información del server (tomcat)? No quiero verificarlo tampoco.

EDITAR:

Inicialmente revisé todo lo anterior excepto el directory de compilation, por supuesto. Cuando revisé el proyecto desde dentro de Eclipse, no me incitó a crear un nuevo proyecto, ya que el .project está allí, pero Eclipse estaba creando un proyecto JavaEE o algo así en lugar de Dynamic Web Project. ¿Alguien más se encontró con este comportamiento?

** EDITAR 2 **

¡Lo encontré! Resulta que no debería verificar lo siguiente:

  • .proyecto
  • .settings /
  • .classpath

Una vez que se eliminan estos 3, el asistente de proyecto nuevo funciona como se esperaba y todo está bien.

Si .classpath/.project/.settings usted hace que su proyecto sea específico de Eclipse. ¿Qué hay de los desarrolladores que trabajan con Netbeans o IntelliJ ? IMO es más limpio para mantener su proyecto independiente de IDE y fácil de configurar.

Suelo search una versión de Maven. El pom.xml especifica todas las dependencies requeridas y mvn eclipse:eclipse genera los files .classpath/.project para usted.

El directory .settings contiene configuraciones locales (como qué versión de Java quieres usar). IMO no es útil para verificar esto. Puede hacer cumplir la versión de Java a través de Maven2 pom.

Finalmente, para su próximo proyecto, mi prototipo es svn-ignore los files o directorys que no desea en SVN antes de su primer commit. En una configuration Maven2 que sería .settings .classpath .settings .classpath .project (el directory de salida pnetworkingeterminado de Maven2) y cualquier otro material generado (files de logging, directorys de gfembed, etc.). En tu caso, ignorarías build y dist lugar de target .

Puede svn-ignore files o directorys con RIGHT_MOUSE->Team->'Add to svn:ignore' (uso el plugin Subclipse). Las instrucciones Ignorar se almacenan como svn-properties en el directory principal. RIGHT_MOUSE->Team->Show properties puede ver las properties de un directory. También puede editar las properties directamente allí haciendo clic en el campo de valor. Asegúrese de que haya un final de línea después de cada propiedad.

Ahora que ya has cometido y luego eliminado estos files, ignorarlos ya no funcionará en mi experiencia. De alguna manera, nunca he logrado ignorar con éxito los files generados que alguna vez se han registrado en el repository SVN; son como zombies, siempre regresan de entre los muertos. Tal vez al eliminar sus inputs físicamente en el repository SVN esto se puede lograr, pero nunca lo he hecho.

En nuestro caso, hemos registrado todo lo que mencionó en la list excepto, .settings /.

Con .classpath y .project , los usuarios pueden consultar rápidamente el proyecto y arrancar Eclipse en una computadora nueva y simplemente comenzar a trabajar en él; la alternativa es configurar el proyecto de forma manual y agregar todas las dependencies jar de manera minuciosa (si usa ant). Muchos proyectos de código abierto hacen esto.

Lea esto , hay algunos puntos realmente buenos para reflexionar.

Buena pregunta … Muchos de nosotros estamos en un dilema sobre si queremos verificar files relacionados con IDE o no. Normalmente voy a registrar. Classpath for eclipse y uso las variables de eclipse para asegurarme de que el equipo solo necesita cambiar el valor de la variable y funciona. También registramos .project para que el equipo no necesite crear un nuevo proyecto en su área de trabajo.

Yo omitiría el .project, .settings /, dist y build.

El .classpath se puede dejar si usa variables en lugar de routes codificadas. Esto es útil para que no tenga que rebuild su classpath cada vez que revisa el proyecto.