¿Qué archivos se deben agregar a SVN en un proyecto de eclipse Java?

Question

Tengo un proyecto Java que me gustaría enviar a mi repositorio SVN, creado con eclipse.

Ahora, ¿qué archivos (aparte del código fuente, obviamente) son necesarios? En la raíz del espacio de trabajo, hay una carpeta .settings con muchos archivos y subcarpetas, y dentro de la carpeta del proyecto hay dos archivos - .classpath y .project, y otra carpeta .settings con un solo archivo - org.eclipse.jdt.core .prefs.

¿Cuáles de estos archivos deben asignarse a SVN y cuáles se pueden excluir de manera segura?

Answer 1

Son todos útiles si desea tener configuraciones uniformes en todo su equipo.

.classpath y .project significa que todos pueden comenzar a utilizar un proyecto simplemente importándolo. Cualquier cambio en las bibliotecas y archivos fuente incluidos en el proyecto será recogido por todos cuando estén registrados.

El directorio .settings tiene cosas como opciones de formato de código y lo que el compilador considera como advertencias, errores o Aceptar . Para ser consecuente, también he comenzado a verificar esto (siempre que todos en su equipo puedan aceptar un estándar para el formateo, supongo).

Descubrí que la mayor limitación para compartir cosas en el control de versiones en Eclipse se encuentra en las definiciones de la biblioteca. Parece que las definiciones de la biblioteca solo se almacenan por usuario, por lo que si hace referencia a una "biblioteca" en el archivo .classpath, cada otro usuario debe definir manualmente el contenido de esa biblioteca (o importar manualmente el archivo de definiciones de biblioteca exportado) .

---

Editar:(comentario de direccionamiento @ mliebelt abajo)

tan solo te comprometes .settings archivos si usted está tratando de mantener la coherencia/estandarización entre los desarrolladores. Si eso no es un problema para el proyecto, entonces no comprometer los archivos .settings es una cosa menos de la que preocuparse. Los archivos que son específicos de los plugins favoritos de un individuo probablemente tampoco necesiten comprometerse (aunque no creo que les perjudique si lo fueran, probablemente los ignorarían).

Los dos más comunes que he encontrado que vale la pena comprometer son org.eclipse.jdt.core.prefs y org.eclipse.jdt.ui.prefs, que son fundamentales para cualquier proyecto (de Java) Eclipse.

Answer 2

Puede excluir la carpeta .settings, pero el archivo .project será útil para otros desarrolladores que deseen reconstruir el mismo proyecto Eclipse exacto. Si examina el archivo, solo debería tener referencias relativas (si no es así, debe modificarlo como tal).

Answer 3

En contraste con las otras respuestas, he tenido mejores experiencias con sin registrar el archivo .project en grandes proyectos de código abierto con los que trabajo.

Puede estar en desacuerdo conmigo, pero hay un problema con los archivos .project compartidos: Contienen referencias a las naturalezas del proyecto utilizadas en el proyecto. Las naturalezas del proyecto nuevamente dependen de los complementos instalados en la máquina de desarrollo local.

Ejemplo: Si utiliza Findbugs en un proyecto Java, se agrega una nueva naturaleza a su proyecto Java.Verificar ese archivo, modificarlo en otro sistema (sin Findbugs instalado) y luego usarlo nuevamente en mi sistema, me ha llevado a perder la referencia de Findbugs (y, por lo tanto, todas las revisiones de Findbugs se eliminan silenciosamente).

Pero si puede hacer que todos sus desarrolladores acepten usar las mismas herramientas, entonces podrá evitar este problema fácilmente.