205 votos

¿Qué archivos de eclipses pertenecen al control de versiones

¿Qué archivos de eclipses es apropiado poner bajo control de la fuente, aparte de las fuentes obviamente. En mi proyecto, específicamente, me estoy preguntando sobre:

.metadatos/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*

Si hay alguna de estas cosas de las que depende, por favor explique sus pautas.

149voto

VonC Puntos 414372

Los metadatos no deben gestionarse en el control de la fuente, ya que contienen sobre todo datos pertinentes para tu espacio de trabajo.

La única excepción es la .launch archivos xml (definición de lanzador).

Se encuentran en

[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches

Y debe ser copiado en el directorio de su proyecto: cuando su proyecto se actualice, esas configuraciones se mostrarán en el diálogo "Ejecutar configuración".
De esa manera, esos archivos de parámetros de lanzamiento también pueden ser administrados en el SCM.

(Advertencia: hacer desmarcar la opción "Eliminar configuraciones cuando se elimine el recurso asociado" en el panel de preferencias de Ejecutar/Lanzar/Configuración de Lanzamiento: es común borrar en forma suave un proyecto para importarlo de nuevo - para forzar una reinicialización de los metadatos del eclipse. Pero esta opción, si está marcada, eliminará los parámetros de lanzamiento detallados)

project-dir/.project
project-dir/.classpath
project-dir/.settings/* 

debería estar en su MEC (especialmente .project y .classpath de acuerdo con el eclipse docs ).

El objetivo es que cualquiera pueda comprobar/actualizar su espacio de trabajo SCM e importar el proyecto del eclipse al espacio de trabajo del eclipse.

Para eso, usted quiere usar sólo caminos relativos en su .classpath, usando recursos vinculados .

Nota: es mejor si project-dir se refiere a un directorio de proyecto "externo", no a un directorio creado bajo el espacio de trabajo del eclipse. De esta manera, las dos nociones (espacio de trabajo del eclipse vs. espacio de trabajo del SCM) están claramente separadas.


Como ipsquiggle menciona en el comentario, y como he aludido a en una vieja respuesta puedes guardar la configuración de lanzamiento como archivo compartido directamente en su directorio de proyectos. Toda la configuración de lanzamiento puede ser versionada como los otros archivos del proyecto.

(De la entrada del blog Consejo: Crear y compartir configuraciones de lanzamiento de KD)

alt text

12voto

pdemarest Puntos 777

Actualmente estoy trabajando en un proyecto en el que tenemos los archivos .project y .cproject bajo el control de la fuente. La idea era que los ajustes relacionados 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 hay que desconficar fuera del eclipse y luego el proyecto se cerró y reabrió para que los cambios surtan efecto.

No recomendaría mantenerlos en el control de la fuente.

9voto

Diaa Sami Puntos 1802

No vale la pena que los archivos de configuración del CDT no sean compatibles con el control de fuentes, hay un error archivado para los archivos .cproject que cambia muy frecuentemente y causa conflictos, ver https://bugs.eclipse.org/bugs/show_bug.cgi?id=226457

6voto

John Stoneham Puntos 1673

Algunos proyectos, como los que usan Maven, les gusta generar los archivos .project basados en POMs.

Dicho esto, aparte de eso, los metadatos NO deben estar en el control de la fuente. Su proyecto tendrá que determinar si el projectdir/.settings lo hace, basándose en la forma en que planea manejar los estándares y demás. Si puedes confiar honestamente en tus desarrolladores para configurar su entorno basado en el estándar, y no tienes que personalizar nada especial para ningún proyecto, entonces no necesitas ponerlos. Yo, recomiendo configurar cada proyecto específicamente. Esto permite a los desarrolladores trabajar en varios proyectos en el mismo espacio de trabajo sin tener que cambiar la configuración predeterminada una y otra vez, 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 no quieres específicamente en el control de fuentes, haz el equivalente a establecer svn:ignore para ellos, si tu SCM lo soporta.

5voto

agnul Puntos 2828

Yo diría que ninguno de ellos. Lo más probable es que contengan información que sólo sea relevante para su estación de trabajo (estoy pensando en los caminos para las bibliotecas y todo eso). ¿Y qué pasa si alguien de tu equipo no está usando Eclipse?

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X