2010-08-19 23 views
15

Quiero registrar un proyecto de web dinámico que creé en eclipse en svn. ¿Puede alguien decirme qué archivos 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 dinámico nuevamente. Más específicamente aquí están los archivos/directorios que tengo en el proyecto -Comprobando un proyecto de Eclipse en el SVN

  • src
  • WebContent
  • acumulación
  • dist
  • build.xml
  • .project
  • .classpath
  • .settings/

No se supone que el directorio de compilación se haya registrado de forma obvia. ¿Qué hay de los otros? Supongo que todo. los archivos tampoco deben estar marcados. ¿Puede alguien verificar esto? ¿Qué es este directorio dist y el directorio .settings?

¿Dónde guarda eclipse la información del servidor (tomcat)? No quiero verificarlo tampoco.

EDIT:

Inicialmente comprueba en todos los anteriores, excepto el directorio de construcción, 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?

** ** EDIT 2

encontré! Resulta que yo no debería comprobar en el siguiente -

  • .project
  • .settings/
  • .classpath

Una vez que estos 3 se quitan el Asistente para nuevo proyecto funciona como se espera y todo está bien.

Respuesta

13

Si marca .classpath/.project/.settings, hace que su proyecto sea específico de Eclipse. ¿Y 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 elegir una versión de Maven. El pom.xml especifica todas las dependencias requeridas y mvn eclipse:eclipse genera los archivos .classpath/.project por usted.

El directorio .settings contiene configuraciones locales (como la versión de Java que desea 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 archivos o directorios que no desea en el SVN antes de su primer compromiso. En una configuración Maven2 que sería .settings.classpath.projecttarget (el directorio de salida predeterminado de Maven2) y cualquier otro material generado (archivos de registro, directorios gfembed, etc.). En su caso, ignoraría build y dist en lugar de target.

Puede svn-ignore archivos o directorios con RIGHT_MOUSE->Team->'Add to svn:ignore' (uso el plugin Subclipse). Ignorar instrucciones se almacenan como svn-properties en el directorio principal. Las propiedades en un directorio se pueden ver en RIGHT_MOUSE->Team->Show properties. También puede editar las propiedades 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 ha confirmado y eliminado estos archivos, ignorarlos ya no funcionará en mi experiencia. De alguna manera, nunca he logrado ignorar con éxito los archivos generados que alguna vez se han registrado en el repositorio SVN; son como zombies, siempre regresan de entre los muertos. Tal vez al eliminar sus entradas físicamente en el repositorio SVN esto se puede lograr, pero nunca lo he hecho.

+0

Gracias ese es un buen punto sobre el IDE específico archivos y es una buena idea usar svn Ignorar también. – user220201

+0

Si bien el contenido de .settings es específico de Eclipse, eso no significa que no deba compartirse con otros miembros de su equipo. Específicamente, es posible que desee compartir sus preferencias de advertencia JDT para su proyecto. Sería un verdadero dolor compartirlos al generarlos. –

+0

Buen punto. A veces comparto dicha configuración exportándola del IDE y compartiendo los archivos. Por ejemplo, Eclipse permite exportar las reglas de formato y plantilla de código. Otro ejemplo es la configuración del estilo de control. Todos estos ajustes suelen ser políticas de toda la empresa, por lo que a menudo se los encuentra en la wiki de Confluence, no registrados en cada proyecto. –

0

Omitiría el .project, .settings /, dist y compilación.

.classpath se puede dejar si usa variables en lugar de rutas codificadas. Esto es útil para que no tengas que reconstruir tu classpath cada vez que revises el proyecto.

11

En nuestro caso, hemos registrado todo lo que ha mencionado en la lista excepto, .settings /.

Con .classpath y .project registrado, los usuarios pueden comprobar rápidamente el proyecto y encender 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 dependencias jar de manera minuciosa (si usa ant). Muchos proyectos de código abierto hacen esto.

Lea this, hay algunos puntos realmente buenos para considerar.

+0

Enlace muerto a la publicación del blog, la nueva URL es: http://lousycoder.blogspot.com/2008/09/arguments-against-checking-in-your.html – David

2

Buena pregunta ... Muchos de nosotros estamos en un dilema sobre si queremos verificar archivos 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.

Cuestiones relacionadas