¿Qué archivos de Eclipse es apropiado poner bajo control de código fuente, aparte de las fuentes obviamente?¿Qué archivos de Eclipse pertenecen al control de versión?
En mi proyecto, en concreto, me pregunto acerca de:
.metadata/*
proyecto-dir/.project
proyecto-dir/.classpath
proyecto-dir/.settings/*
Si de alguno de estos depende, explique sus indicaciones.
Los metadatos no se deben administrar en el control de fuente. Contienen principalmente datos relevantes para su espacio de trabajo.
La única excepción son los archivos XML .launch (definición del iniciador).
Se encuentran en
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
Y se debe copiar en el directorio del proyecto: Cuando el proyecto se actualiza, estas configuraciones se mostrarán en el cuadro de diálogo "Configuración de ejecución".
De esta forma, esos archivos de parámetros de inicio también se pueden administrar en el SCM.
(Advertencia: desmarque la opción "Borrar configuraciones cuando se elimina recurso asociado" en el Run/Lanzamiento/configuración de lanzamiento del panel preferencia: Es común suave eliminar un proyecto con el fin importarlo de nuevo - para forzar una reinicialización de los metadatos Eclipse Pero esta opción, si está marcada, eliminará los parámetros detallados de lanzamiento)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
debería estar en su SMC (especialmente .project.! y .classpath según el Eclipse documentation).
El objetivo es que cualquier persona pueda pagar/actualizar su espacio de trabajo SCM e importar el proyecto Eclipse al espacio de trabajo de Eclipse.
Para ello, conviene usar rutas relativas en su .classpath, utilizando linked resources.
Nota: es mejor si project-dir se refiere a un directorio "externa" del proyecto, no es un directorio creado en el marco del espacio de trabajo de Eclipse. De esta forma, las dos nociones (espacio de trabajo eclipse vs. espacio de trabajo SCM) están claramente separadas.
Como ipsquiggle menciona en el comentario, y como ya he aludido a in an old answer, en realidad se puede guardar la configuración de lanzamiento como archivo compartida directamente en el directorio del proyecto. Toda la configuración de lanzamiento puede ser versionada como los otros archivos de proyecto.
(A partir de la entrada en el blog Tip: Creating and Sharing Launch Configurations de KD)
diría que ninguna de ellas. Lo más probable es que contengan información que sea relevante solo para su estación de trabajo (estoy pensando en rutas para bibliotecas y todo). Además, ¿qué sucede si alguien de tu equipo no está utilizando Eclipse?
No, puedes tener rutas relativas en tu .classpath. Ver http://stackoverflow.com/questions/300328#300346. – VonC
Suena como un equipo bastante incoherente/ineficiente si no están utilizando el mismo desarrollador. definiciones de herramientas, proyectos, depuración y compilación, etc. - A continuación, me dirá que no use un estándar de codificación común o JDK. - Idealmente, un usuario debería ser capaz de desplegar un proyecto desde el control de origen e ingresar directamente sin demasiadas configuraciones o instrucciones adicionales. Entonces esta respuesta es simplemente inaceptable para mí. – BrainSlugs83
Es mucho más ineficaz tratar con los conflictos en los archivos de preferencias durante una combinación, solo porque alguien abrió el proyecto desde un nuevo espacio de trabajo; esto es una pesadilla en los proyectos grandes. Además, forzar el uso del mismo IDE con exactamente la misma configuración suena como una restricción innecesaria. –
Actualmente estoy trabajando en un proyecto donde tenemos los archivos .project y .cproject bajo control de fuente. La idea era que las configuraciones relacionadas con las rutas de las bibliotecas y las directivas de enlaces se propagarían a través del equipo.
En la práctica, no funcionó muy bien, las fusiones casi siempre vuelven en un estado conflictivo que debe ser liberado 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.
A algunos proyectos, como los que utilizan Maven, les gusta generar los archivos .project basados en POM.
Dicho esto, aparte de eso - .metadata NO debe 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 según el estándar, y no tiene que personalizar nada especial para ningún proyecto, entonces no necesita colocarlos. Yo, recomiendo configurar cada proyecto específicamente. . Esto permite a los desarrolladores trabajar en las tareas de múltiples proyectos en el mismo espacio de trabajo sin tener que cambiar la configuración predeterminada, y hace que la configuración sea muy explícita, anulando cualquier configuración predeterminada que coincida con los estándares del proyecto.
La parte más 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 específicamente no desee en el control de la fuente, haga el equivalente a configurar svn: ignore para ellos, si su SCM lo admite.
Usamos Maven 1 y 2, y solo genera el archivo .project si así lo solicita. E incluso si lo hace, lo hace en función de los contenidos del POM, de modo que si otro desarrollador ya ha hecho ese paso por usted y comprobado el resultado en el control de la versión, ¿por qué no aprovecharlo? –
Es destacable que CDT archivos de configuración no son de código de control de ambiente. Se ha producido un error para que los archivos .cproject cambien con mucha frecuencia y provoquen conflictos, consulte Sharing cdt-project files in repository always causes conflicts.
Yikes: este error tiene seis años y todavía no se ha tocado. ¡Claramente, el soporte de control de fuente no es una prioridad para el equipo de Eclipse! – BrainSlugs83
También se debe tener en cuenta que el archivo .cproject contiene información de configuración que preferiría no obligar a otros desarrolladores a recrear manualmente. Ugh. –
archivo La .classpath es definitivamente un buen candidato para el ingreso en SCM como el establecimiento a mano puede ser un montón de trabajo y será difícil para los nuevos desarrolladores de entrar en el proyecto. Es cierto que se puede generar a partir de otras fuentes, en cuyo caso se verificaría 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 ver un proyecto, importarlo en Eclipse y tener todo listo y listo para funcionar.
En nuestro proyecto, por lo tanto, mantener una copia de la carpeta .settings llamados CVS.settings y tenemos una tarea ant para copiarlo en .settings. Cuando obtiene el proyecto de CVS, llama a la tarea 'eclipsify' para copiar la configuración predeterminada a la nueva carpeta .settings. Cuando configura los ajustes que necesitan todos los desarrolladores del proyecto, los fusiona nuevamente en la carpeta CVS.settings y los confirma a CVS. De esta forma, guardar las configuraciones en SCM se convierte en un proceso consciente. Requiere devs para fusionar esas configuraciones de nuevo en sus carpetas .settings de vez en cuando cuando se registran grandes cambios. Pero es un sistema simple que funciona sorprendentemente bien.
considerar:
.classpath
.project
.launch
Estos deben estar en control de versiones, siempre y cuando se apegue a la utilización de rutas relativas a proyectos. Esto permite que otros desarrolladores revisen el proyecto y comiencen a trabajar de inmediato sin tener que pasar por todos los problemas de configuración que otros desarrolladores también sufrieron.
Usted puede verse tentado a incluir .metadata en el control de versiones, así que los desarrolladores de Eclipse pueden desproteger un espacio de trabajo entero y tenerlo preconfigurado con todos los proyectos adecuados, sino que incluye una gran cantidad de información específica de usuario que en cualquier momento alguien trabaja en cambiará, por lo que le aconsejaría NO INCLUIR .metadata. Es fácil construir un espacio de trabajo local simplemente importando todos los proyectos de Eclipse existentes.
En mi experiencia, esto tiende a romperse de varias maneras cuando actualiza Eclipse a una versión más nueva o cambia de sabores. –
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 desarrolladora.
Si está trabajando en un equipo, entonces creo que los siguientes son muy buenos candidatos para mantener bajo control de versiones:
A (OMI) mucho mejor flujo de trabajo para trabajar con cualquier cosa en .metadata para los archivos .launch, es: cuando se edita una configuración de lanzamiento, el la pestaña 'común', elija 'Guardar como> archivo compartido'. Esto lo coloca directamente en la carpeta del proyecto, por lo que puede ser SCM'd con el resto del proyecto. – Ipsquiggle
@lpsquiggle: buen punto. He completado mi respuesta para reflejar mejor esa posibilidad. – VonC
¿Por qué debería .project estar en SCM? Por ejemplo, quiero usar una herramienta de métricas de código que causa cambios en .project cuando está habilitado. No me gustaría obligar a todos los usuarios del proyecto. – jfritz42