¿Qué archivos de Eclipse pertenecen al control de versiones?
¿Qué archivos de Eclipse es apropiado poner bajo control de código fuente, aparte de las fuentes, obviamente?
En mi proyecto, específicamente, me pregunto acerca de:
.metadata/*
dir-proyecto/.project
dir
-proyecto/.classpath dir-proyecto/.settings/*
Si hay alguno de estos del que depende, explique sus pautas.
Los metadatos no deben gestionarse en el control de código fuente. 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 actualice 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 inicio 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 temporalmente un proyecto para importarlo nuevamente, para forzar una reinicialización del metadatos de eclipse. ¡Pero esta opción, si está marcada, eliminará los parámetros de inicio detallados!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
debe estar en su SCM (especialmente .projecty .classpathde acuerdo con la documentación de Eclipse ).
El objetivo es que cualquiera pueda verificar/actualizar su espacio de trabajo SCM e importar el proyecto de Eclipse al espacio de trabajo de Eclipse.
Para eso, desea utilizar solo rutas relativas en su .classpath, utilizando recursos vinculados .
Nota: es mejor si project-dirse refiere a un directorio de proyecto "externo", no a un directorio creado en el espacio de trabajo de eclipse. De esa manera, las dos nociones (espacio de trabajo eclipse versus espacio de trabajo SCM) están claramente separadas.
Como menciona ipsquiggle en el comentario, y como mencioné en una respuesta anterior , puede guardar la configuración de inicio como un archivo compartido directamente en el directorio de su proyecto. Luego, toda la configuración de inicio se puede versionar como los demás archivos del proyecto.
(De la publicación del blog Consejo: Crear y compartir configuraciones de lanzamiento desde KD)
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 enlace se propagaran por todo el equipo.
En la práctica, no ha funcionado muy bien, las fusiones casi siempre regresan en un estado conflictivo que debe solucionarse 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 la pena que los archivos de configuración CDT no sean compatibles con el control de fuente. Hay un error presentado para los archivos .cproject que cambian con mucha frecuencia y causan conflictos; consulte Compartir archivos cdt-project en el repositorio siempre causa conflictos .
A algunos proyectos, como los que usan Maven, les gusta generar archivos .project basados en POM.
Dicho esto, aparte de eso, .metadatos NO deberían estar en el control de fuente. Su proyecto tendrá que tomar una determinación sobre si projectdir/.settings lo hace, en función de cómo planea administrar los estándares y demás. Si honestamente puedes confiar en que tus desarrolladores configurarán su entorno según el estándar y no tienes que personalizar nada especial para ningún proyecto, entonces no necesitas incluirlos. Yo recomiendo configurar cada proyecto específicamente. . Esto permite a los desarrolladores trabajar en 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 cualquiera que sea su configuración predeterminada para que coincida 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 puedes copiar los archivos .settings de un proyecto a otro. Si hay alguno que específicamente no desea en el control de fuente, haga el equivalente a configurar svn:ignore para ellos, si su SCM lo admite.
