¿Qué archivos de Eclipse es apropiado poner bajo control de la fuente, aparte de las fuentes obviamente?
En mi proyecto, específicamente, me pregunto sobre:
.metadata / *
project-dir / .project
project-dir / .classpath
project-dir / .settings / *
Si hay alguno de estos de los cuales depende, explique sus pautas.
Respuestas:
Los metadatos no deben gestionarse en el control de origen. Contienen principalmente datos relevantes para su espacio de trabajo.
La única excepción son los .launcharchivos XML (definición del iniciador).
Se encuentran en
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
Y deben copiarse en el directorio de su proyecto: cuando se actualiza su proyecto, esas configuraciones se mostrarán en el cuadro de diálogo "Ejecutar configuración".
De esa manera, esos archivos de parámetros de lanzamiento también se pueden administrar en el SCM.
(Advertencia: desmarque la opción "Eliminar configuraciones cuando se elimine el recurso asociado" en el panel de preferencias Ejecutar / Iniciar / Iniciar configuración : es común eliminar un proyecto para volver a importarlo de nuevo, para forzar una reinicialización del metadatos de eclipse. ¡Pero esta opción, si está marcada, eliminará sus parámetros detallados de inicio!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
debe estar en su SCM (especialmente .projecty de .classpathacuerdo con la documentación de Eclipse ).
El objetivo es que cualquiera pueda pagar / actualizar su espacio de trabajo SCM e importar el proyecto Eclipse al espacio de trabajo Eclipse.
Para eso, desea utilizar solo rutas relativas en su .classpath, utilizando recursos vinculados .
Nota: es mejor si se project-dirrefiere a un directorio de proyecto "externo", no a un directorio creado bajo el espacio de trabajo de eclipse. De esa manera, las dos nociones (espacio de trabajo eclipse vs. espacio de trabajo SCM) están claramente separadas.
Como menciona ipsquiggle en el comentario, y como he mencionado en una respuesta anterior , en realidad puede guardar la configuración de inicio como archivo compartido directamente en el directorio de su proyecto. Toda la configuración de inicio se puede versionar como los otros archivos del proyecto.
(De la publicación del blog Consejo: Creación y uso compartido de configuraciones de lanzamiento desde KD)
.projectignorada por el momento sea solo para su espacio de trabajo. Pero no prive a todos los demás usuarios de la definición común de proyecto de Eclipse que pueden importar rápidamente en su espacio de trabajo de Eclipse, solo porque tiene una definición adicional que se adaptaría solo a su necesidad del momento.
Actualmente estoy trabajando en un proyecto donde tenemos los archivos .project y .cproject bajo control de código fuente. La idea era que las configuraciones relacionadas con las rutas de la biblioteca y las directivas de enlaces se propagarían por todo el equipo.
En la práctica, no ha funcionado muy bien, las fusiones casi siempre regresan en un estado conflictivo que debe desconfigurarse fuera del eclipse y luego el proyecto se cierra y se vuelve a abrir para que los cambios surtan efecto.
No recomendaría mantenerlos en control de fuente.
No vale nada que los archivos de configuración de CDT no sean compatibles con el control de origen. Se ha registrado un error para los archivos .cproject que cambian con mucha frecuencia y causan conflictos. Consulte Compartir archivos de proyecto cdt en el repositorio siempre causa conflictos .
Algunos proyectos, como los que usan Maven, les gusta generar los archivos .project basados en POM.
Dicho esto, aparte de eso, .metadata NO debería estar en control de fuente. Su proyecto tendrá que determinar si projectdir / .settings lo hace, en función de cómo planea administrar los estándares y demás. Si puede confiar honestamente en que sus desarrolladores configuren su entorno en función del estándar, y no tiene que personalizar nada especial para ningún proyecto, entonces no necesita ponerlos. Yo, le recomiendo configurar cada proyecto específicamente . Esto permite a los desarrolladores trabajar en cosas de múltiples proyectos en el mismo espacio de trabajo sin tener que cambiar la configuración predeterminada de un lado a otro, y hace que la configuración sea muy explícita, anulando cualesquiera que sean sus configuraciones predeterminadas para que coincidan con los estándares del proyecto.
La única parte difícil es asegurarse de que todos estén sincronizados. Pero en la mayoría de los casos, puede copiar los archivos .settings de un proyecto a otro. Si hay alguno que no desee específicamente en el control de fuente, haga el equivalente de configurar svn: ignórelo si su SCM lo admite.
El archivo .classpath es definitivamente un buen candidato para registrarse en scm, ya que configurarlo a mano puede ser mucho trabajo y será difícil para los nuevos desarrolladores ingresar al proyecto. Es cierto que puede generarse a partir de otras fuentes, en cuyo caso debería verificar en la otra fuente.
En cuanto a .settings, depende de la configuración. Esta es un área gris, pero algunas configuraciones son casi obligatorias y es conveniente poder verificar un proyecto, importarlo en Eclipse y tener todo listo y listo.
En nuestro proyecto, por lo tanto, mantenemos una copia de la carpeta .settings llamada CVS.settings y tenemos una tarea ant para copiarla en .settings. Cuando obtiene el proyecto de CVS, llama a la tarea ant 'eclipsify' para copiar la configuración predeterminada a la nueva carpeta .settings. Cuando configura los ajustes que necesitan todos los que se desarrollan en el proyecto, los combina nuevamente en la carpeta CVS.settings y los confirma en CVS. De esta forma, guardar la configuración en SCM se convierte en un proceso consciente. Requiere que los desarrolladores fusionen esas configuraciones nuevamente en sus carpetas .settings de vez en cuando cuando se registran grandes cambios. Pero es un sistema simple que funciona sorprendentemente bien.
Yo diría que ninguno de ellos. Lo más probable es que contengan información relevante solo para su estación de trabajo (estoy pensando en rutas para bibliotecas y todo). Además, ¿qué pasa si alguien en su equipo no está usando Eclipse?
Considerar:
.classpath
.project
.launch
Estos DEBEN estar en control de versiones siempre y cuando se apegue a usar rutas relativas al proyecto. Esto permite a otros desarrolladores revisar el proyecto y comenzar a trabajar de inmediato sin tener que pasar por todo el problema de configuración que otros desarrolladores también experimentaron.
Es posible que sienta la tentación de incluir .metadata en el control de versiones para que los desarrolladores de Eclipse puedan revisar un espacio de trabajo completo y tenerlo preconfigurado con todos los proyectos correctos, pero incluye una gran cantidad de información específica del usuario que siempre que alguien trabaje en él, lo hará cambiar, por lo que aconsejaría NO INCLUIR .metadata. Es fácil construir un espacio de trabajo local simplemente importando todos los proyectos Eclipse existentes.
He pasado demasiadas horas configurando la configuración del espacio de trabajo de eclipse para nuevos colegas (y para mí). Lo que finalmente terminé haciendo fue copiar mis propios metadatos a la nueva máquina de desarrollo.
Si está trabajando en un equipo, creo que los siguientes son muy buenos candidatos para mantener bajo control de versión:
commonpestaña, elijaSave as > shared file. Esto lo deja directamente en la carpeta del proyecto, por lo que puede ser SCM con el resto del proyecto.