Que Eclipse archivos es apropiado para poner bajo control de código fuente, aparte de las fuentes obviamente?

En mi proyecto, en concreto, me pregunto acerca de:

.los metadatos/*

proyecto-dir/.proyecto

proyecto-dir/.classpath

proyecto-dir/.ajustes/*

Si hay alguno de estos de los que depende, por favor explique sus directrices.

InformationsquelleAutor sblundy | 2008-12-03

8 Comentarios

  1. 173

    Metadatos no debe ser administrado en el control de código fuente. Contienen la mayoría de datos relevantes para su área de trabajo.

    La única excepción es el .launch archivos XML (lanzador de definición).

    Que se encuentran en

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

    Y que debe ser copiado en el directorio del proyecto: Cuando el proyecto se actualiza, estas configuraciones se muestran en la «configuración» del cuadro de diálogo.

    De esa manera, los de lanzamiento de los archivos de parámetros también se pueden administrar en el SCM.

    (Advertencia: no desmarcar la opción de «Eliminar configuraciones cuando se asocia recurso se ha borrado» en el Ejecutar/el Lanzamiento de/Configuración de Lanzamiento de panel de preferencias: es común Que los suaves en vez de eliminar un proyecto para importar de nuevo – a la fuerza una reinicialización del eclipse de metadatos. Pero esta opción, si está activado, se eliminarán detallada de los parámetros de inicio!)

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

    debe estar en el SCM (especialmente .project y .classpath de acuerdo a la Eclipse documentación).

    El objetivo es que cualquier persona puede checkout/actualización de su área de trabajo SCM de importación y el proyecto de Eclipse en el espacio de trabajo de Eclipse.

    Para que, sólo desea utilizar rutas relativas en su .ruta de clases, el uso de enlaces a recursos.

    Nota: es mejor si project-dir se refiere a una «externa» directorio del proyecto, no es un directorio creado bajo el espacio de trabajo de eclipse. De esa manera, los dos conceptos (espacio de trabajo de eclipse vs SCM área de trabajo) están claramente separados.


    Como ipsquiggle menciona en el comentario, y como he aludido a en una respuesta anterior, usted puede ahorrar el lanzamiento de configuración como archivo compartido directamente en el directorio de proyecto. Todos lanzando configuración puede ser versionados como los archivos de proyecto.

    (A partir de la entrada en el blog Sugerencia: Crear y Compartir el Lanzamiento de Configuraciones de KD)

    Que Eclipse archivos pertenecen bajo el control de versiones?

    • Un (OMI) mucho mejor flujo de trabajo para trabajar con cualquier cosa en .metadatos para la .el lanzamiento de los archivos, es: cuando se edita una configuración de lanzamiento, en el common ficha, seleccione Save as > shared file. Esto gotas directamente en la carpeta del proyecto, por lo que puede ser SCM d con el resto del proyecto.
    • buen punto. He completado mi respuesta para reflejar mejor esa posibilidad.
    • ¿Por qué debería .proyecto de la SCM? Por ejemplo, desea utilizar un código de métricas herramienta que hace que los cambios en .proyecto cuando se activa. Yo no quiero a la fuerza que en todos los usuarios del proyecto.
    • si haces un local y puntual de cambio válido sólo para usted, a continuación, hacer que versionned .project ignorado por el momento sólo para su área de trabajo. Pero no privar a todos los otros usuarios de la común Eclipse de definición de proyecto que rápidamente se puede importar en su espacio de trabajo de Eclipse, sólo porque usted tiene un extra de definición que sólo se ajuste a su necesidad del momento.
    • Es el lanzamiento de configuración debe estar en la raíz del proyecto? Los puse en un subdirectorio del directorio y no se carga con el proyecto cuando hacemos una compra.
    • consulte stackoverflow.com/questions/952290/… (PROJECT_LOC/.setting funciona automáticamente, pero en otros lugares se requiere un poco más de trabajo).
    • Es este un correcto «take-away»: 1. Tiene su SCM ignorar .los metadatos 2. Guardar el lanzamiento de configuraciones en el proyecto. 3. Sonríe, todo está bien ahora.
    • la idea principal es tener suficiente información en el VCS para cualquier persona que acceda al contenido versionado para ser capaces de «»: ver stackoverflow.com/questions/2818239/… y stackoverflow.com/questions/116121/…. El que se presupone que sólo tiene rutas relativas en los archivos de proyecto, no la ruta de acceso absoluta dependientes de un entorno dev.
    • Gracias. Voy a estudiar los vínculos con cuidado, pero ya me doy cuenta de que en el primero de los enlaces de una respuesta empieza «Definitivamente sí», mientras que la próxima comienza «Defininitely no». Google está lleno de variables, novato que no toleran el consejo. Entiendo el objetivo, pero, ¿cómo llegar allí es el problema. Yo vengo de Xcode donde la fuente y las opciones de usuario se separa limpiamente de Xcode y generados generado por el compilador de salida por lo que esta pregunta tiene una respuesta sencilla. Para el Eclipse novato, me parece que los archivos son mezclados y dispersos. Estoy buscando un simple, comprensible answr
    • Yo vengo de VisualStudio de la tierra, y en la segunda @garyp aquí-esto es realmente un lío caliente — si Eclipse necesita en forma temporal y/o innecesarios-a-por-los archivos de usuario, se debe poner en otra parte, por lo que el proyecto y las definiciones de compilación pueden ser rastreados y todos los temporales de basura no se interponga en el camino. No hay algo más de una guía oficial de el equipo Eclipse en algún lugar? (Es bastante claro que el equipo eclipse no de la unidad de prueba [o, si lo hacen, no lo hacen de manera efectiva], pero al menos me dicen que el uso de control de código fuente! XD)
    • Pero si desea compartir este proyecto públicamente como una fuente (como un marco de trabajo), usted no debe compartir eclipse archivos de proyecto… ¿qué debemos hacer ?
    • «project-dir/.settings/* debe estar en tu SCM» – Este post del foro sugiere lo contrario. ¿Por qué usted cree que debería estar en SCM?
    • Cuando escribí esa respuesta hace 8 años, que trabajó bastante bien, pero sí, se puede omitir si quieres.

  2. 16

    Actualmente estoy trabajando en un proyecto donde tenemos el .proyecto y .cproject archivos bajo control de código fuente. La idea era que los ajustes relacionados con la biblioteca de rutas y de enlace de las directivas propague por todo el equipo.

    En la práctica no ha funcionado muy bien, combina casi siempre en un estado de conflicto que deben ser deconflicted fuera de eclipse y, a continuación, el proyecto se cierra y vuelve a abrir para que los cambios surtan efecto.

    Yo no recomendaría mantener en control de código fuente.

  3. 12

    Vale la pena nada de lo que CDT archivos de configuración no son de control de código fuente de usar. Hay un bug presentada por .cproject archivos cambiando muy frecuentemente y provocando conflictos, ver Compartir cdt-archivos de proyecto en el repositorio siempre es causa de conflictos.

    • Uff … este error es de seis años y todavía no se ha tocado. Claramente el control de código fuente de apoyo no es una prioridad para el equipo Eclipse!
    • También se debe señalar que el .cproject archivo contiene la información de configuración que preferiría no obligan a los desarrolladores a tener que volver a crear manualmente. Ugh.
  4. 7

    Algunos proyectos, como los que el uso de Maven, como para generar el .los archivos de proyecto basado en los Pdm.

    Que dijo, aparte de eso – .los metadatos NO debe estar en control de código fuente. El proyecto tendrá que tomar una determinación acerca de si projectdir/.configuración no hace, basándose en el plan de gestión de normas y tal. Si usted honestamente puedo confiar en los desarrolladores para configurar su entorno basado en el estándar, y usted no tiene que personalizar cualquier cosa, especial para cualquier proyecto, entonces usted no necesita ponerlos en. Yo, recomiendo la configuración de cada proyecto en particular. Esto permite a los desarrolladores trabajar en múltiples proyectos » cosas en el mismo espacio de trabajo sin tener que cambiar la configuración por defecto de ida y vuelta, y esto hace que la configuración de la muy explícita, anulando, cualquiera que sea su configuración predeterminada es para que coincida con el del proyecto de normas.

    Única parte difícil es asegurarse de que todos estén sincronizadas. Pero en la mayoría de los casos se pueden copiar los .los archivos de configuración de proyecto a proyecto. Si hay alguno que específicamente no quiere en el control de código fuente, hacer el equivalente de configuración de svn:ignore para ellos, si tu SCM admite.

    • Usamos Maven 1 y 2, y sólo se genera el .archivo de proyecto, si se solicita. E incluso si lo hace, lo hace en el contenido del POM, así que si otro desarrollador ya ha hecho ese paso para que usted y comprueba el resultado en el control de versión, ¿por qué no tomar ventaja de eso?
  5. 6

    El .classpath archivo es definitivamente un buen candidato para la comprobación en scm de la configuración a mano puede ser un montón de trabajo y va a ser difícil para los nuevos desarrolladores de entrar en el proyecto. Es cierto que puede ser generado a partir de otras fuentes, en cuyo caso podría comprobar en la otra fuente.

    Como para .configuración, depende de la configuración. Esta es un área gris, pero algunas opciones de configuración son casi obligatorio, y es conveniente ser capaz de retirar un proyecto de importación en Eclipse y tener todo listo y bueno para ir.

    A nuestro proyecto, por lo tanto, mantener una copia de el .carpeta de configuración llamado CVS.ajustes y tenemos una tarea ant para copiar .los ajustes. Cuando usted consigue el proyecto de CVS, que ustedes llaman «la eclipsify’ tarea ant para copiar la configuración predeterminada para los nuevos .carpeta de configuración. Al configurar las opciones que se necesitan por todo el mundo en desarrollo en el proyecto, la combinación de esos de nuevo en el CVS.configuración de la carpeta y se comprometen a que en CVS. De esta manera la configuración de ahorro de SCM se convierte en un proceso consciente. Se requiere desarrolladores de combinar los ajustes de vuelta a su .la configuración de las carpetas de vez en cuando los grandes cambios se verifican en. Pero es un sistema simple que funciona sorprendentemente bien.

  6. 4

    Yo diría que ninguno de ellos. Lo más probable es que contienen información que es relevante sólo para su estación de trabajo (estoy pensando en rutas de acceso a las bibliotecas y a todos). También ¿qué pasa si alguien en su equipo no es el uso de Eclipse?

    • No, usted puede tener rutas relativas en su .classpath. Consulte stackoverflow.com/questions/300328#300346.
    • Suena como una muy incoherente / ineficiente equipo si no está utilizando el mismo dev. herramientas, proyecto, depuración, y las definiciones de compilación, etc. — La próxima vas a decirme que no uso común de codificación estándar o JDK. — Idealmente, un usuario debe ser capaz de tirar de un proyecto de control de código fuente y saltar a la derecha sin mucho de configuración adicional o instrucciones. Así que la respuesta a esto es simplemente inaceptable para mí.
    • Es la manera más ineficiente para lidiar con los conflictos en la preferencia de archivos durante una combinación, sólo porque alguien abrió el proyecto de una nueva área de trabajo – esto es una pesadilla en proyectos de gran envergadura. Además, obligando a utilizar el mismo IDE con exactamente la misma configuración suena como una restricción innecesaria.
    • Estoy de acuerdo con [~agnul]. Los proyectos deben estar utilizando alguna herramienta de construcción (gradle, maven, ant, etc…) y el IDE debe ser capaz de abrir y configurar el proyecto de la herramienta de creación de archivo de configuración (compilación.gradle, pom.xml, build.xml, etc…) No IDE archivos deben ser de la versión controlada. Todos ellos son desarrolladores de archivos específicos, no en el proyecto de archivos específicos. Que simple no pertenecen en el control de versiones.
  7. 2

    Considerar:

    .classpath
    .project
    .launch
    

    Estos DEBEN estar en control de versiones siempre y cuando se apegue a la utilización de proyecto-rutas de acceso relativas. Esto permite a otros desarrolladores a retirar el proyecto y empezar a trabajar de inmediato sin tener que ir a través de todo el programa de instalación de dolor que otros desarrolladores fue bien.

    Usted podría estar tentado a incluir .metadatos en la versión de control de modo que los desarrolladores de Eclipse puede comprobar fuera de un espacio de trabajo completo y tiene preconfigurado con los todos los proyectos, pero incluye una gran cantidad de información específica de usuario que en cualquier momento que alguien trabaja en ella, se va a cambiar, así que yo aconsejaría a los que NO se INCLUYEN .los metadatos. Es fácil construir un espacio de trabajo local sólo por la importación de todos los proyectos de Eclipse.

    • En mi experiencia, tienden a romperse en varias maneras cuando la actualización de Eclipse a una versión más reciente, o cambiar entre los sabores.
  8. 1

    He pasado demasiadas horas de la configuración de espacio de trabajo de eclipse opciones para los nuevos colegas (y a mí). Lo que hice finalmente fue copiado de mi propia .metadatos para el nuevo desarrollador de la máquina.

    Si usted está trabajando en un equipo, entonces creo que los siguientes son muy buenos candidatos para mantener bajo el control de versiones:

    • Instalado Jre y sus nombres
    • Servidor Entornos De Tiempo De Ejecución
    • Java Editor De Plantillas De
    • Versión De Control De Accesos Directos De Teclado
    • Configuración del Plugin que no proporcionan el proyecto de la configuración específica de
    • Maven configuración
    • Preconfigurado Perspectivas

Dejar respuesta

Please enter your comment!
Please enter your name here