Tenemos el código para un Eclipse RCP aplicación en un espacio de trabajo de Eclipse que contiene varios proyectos Java. Estamos usando Mercurial con un sencillo .hgignore solo *.clase (pero la misma cuestión se refieren a Git).

Incluso un pequeño cambio en el código puede resultar en muchos de los archivos .metadatos para cambiar.

Me gustaría excluir a algunos o todos de los .los metadatos de control de versiones. Si se excluyen por completo, el área de trabajo se pierde.

¿Alguien sabe qué se puede excluir? Alternativamente, ¿cómo podemos crearla si tiramos el código para un nuevo equipo?

  • Me da a entender que usted está almacenando todo el espacio de trabajo de Eclipse en un único repositorio de Mercurial? Han considerado que el almacenamiento de cada proyecto en el repositorio y, a continuación, agrupándolos como subrepositories de un paraguas repositorio para que usted pueda versión de ellos juntos (aunque no sé si Eclipse tiene ningún soporte para que)?
  • Es un plugin basado en el producto, y los proyectos independientes definir cada plugin. Todos son necesarios o el total del producto. Para los proyectos individuales son sólo una parte de la totalidad, que es la razón por la que deseamos almacenar todo el espacio de trabajo de Eclipse en un único repositorio.
InformationsquelleAutor Irish Buffer | 2010-11-25

5 Comentarios

  1. 15

    Los archivos personalmente, soy consciente de que son:

    • versión.ini (no muy emocionante)
    • .plugins/org.eclipse.jdt.core/variablesAndContainers.dat (classpath variables)
    • .plugins/org.eclipse.núcleo.recursos/.proyectos/*/.ubicación de los proyectos en el área de trabajo)

    Algún lugar, tengo un espacio de trabajo de Eclipse utiliza para probar algunos de Eclipse relacionados con las herramientas de que es bastante severamente cortado, pero funciona. Voy a ver si puedo cavar hacia fuera.

    • Gracias! Que trabajado. Yo también tenía que mantener .los metadatos\.plugins\org.eclipse.núcleo.recursos\.y raíz .safetable.
    • He tenido que añadir .los metadatos/.plugins/org.eclipse.wst.jsdt.core/variablesAndContainers.dat así.
  2. 51

    GitHub es el mantenimiento de una comunidad «gitignore», proyecto que los catálogos sugirió filespecs para ignora para varias plataformas, editores y lenguajes: https://github.com/github/gitignore

    Eclipse ignora está aquí: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

    (Si hay otros filespecs que debe saber acerca de, hágales saber!)

    • Un excelente proyecto! Que en particular lista de ignorados tiene dos problemas, a pesar de que: uno es que ignora algunas cosas que te quieren hacer el check in, como .classpath, y la otra es que se trata de cosas dentro de directorios de proyecto, mientras que el OP quiere comprobar en todo el área de trabajo. Si se aplica esa lista a un área de trabajo, sería (creo) ignorar todo .los metadatos de directorio, que iba a perder algunas cosas importantes, como el proyecto .ubicación de archivos. En realidad, sin embargo, el problema aquí es Eclipse, que se mezcla de autoridad y derivados de archivos en un muy ineficiente manera.
  3. 32

    Metadatos y área de trabajo

    Nunca iba a compartir el .metadata carpeta. De hecho, a menos que tenga una razón en particular no me gustaría incluso compartir la carpeta del área de trabajo, pero en lugar de compartir cada proyecto por separado con git. De esa manera el .metadata carpeta siempre va a estar en la carpeta principal de tu repositorio git y usted no tiene que pensar acerca de si es necesario hacer caso omiso de todos modos:

    |-- workspace/
    |  \-- .metadata/
    |  |-- yourProjectOne/
    |  |  \-- .git/
    |  |  |-- .project
    |  |  |-- src/
    |  |  |-- ...
    |  |-- yourProjectTwo/
    |  |  \-- .git/
    |  |  |-- .project/
    |  |  |-- src/
    |  |  |-- ...

    Proyecto Específico

    Probablemente, usted debe siempre compartir la .project archivo y nunca .settings/ archivos. El .classpath puede depender de su entorno, pero no me gustaría sugerir a compartirlo, porque puede provocar conflictos (por ejemplo, si un usuario utiliza openjdk y el otro utiliza sol-jdk. El .settings contiene las preferencias y configuración de eclipse y cambia mucho, por lo que no debe ser compartida. Si bien importar el proyecto después de clonado de git a continuación, usted también no tener ningún tipo de problemas.

    La eclipse documentación afirma lo siguiente sobre la .project de archivo:

    La finalidad de este fichero es la de hacer que el proyecto por sí mismo, por lo que
    que un proyecto que está en zip o en libertad a un servidor puede ser
    correctamente recreado en otra área de trabajo.

    y:

    Si se crea un nuevo proyecto en una ubicación que contiene una ya existente
    archivo de descripción del proyecto, el contenido de ese archivo de descripción de se
    ser honrado como la descripción del proyecto. Una excepción es que el
    nombre del proyecto en el archivo será ignorado si no coincide con el nombre de
    el proyecto que se creó. Si la descripción del archivo en el disco es
    no válida, la creación del proyecto va a fracasar.

    Yo también sugieren el uso de Maven ya que esto le ahorrará un montón de problemas con la gestión de la dependencia y .classpath

    Maven

    La principal diferencia con un proyecto de Maven es que se puede importar el proyecto Maven->»Existente de Proyectos Maven», y por tanto sólo la necesidad de compartir la pom.xml y .project archivo en git. Eclipse, a continuación, crear el .classpath, .settings/ archivos de forma automática. Por lo tanto, obviamente, usted no tendrá que compartir con ellos. Si algo cambia en el pom.xml simplemente ejecutar Maven->»proyecto de Actualización de configuración» y Maven->»Actualización de las dependencias».

    Sin Maven

    Que debe compartir el .project archivo y no la .settings/ carpeta. Puedes considere compartir .classpath pero puede llevar a conflictos, como se explicó anteriormente. Yo sugeriría que no comparta del todo. Utilice el método siguiente para importar el proyecto:

    Después de haber clonado el repositorio git usted puede simplemente utilizar la Importación->»Proyecto Existente de un área de trabajo de» eclipse de honor de la .project archivo, pero se recrea en el .classpath y .settings/ archivos. Después de la importación, deberá configurar el classpath de la mano de Eclipse (y cada vez que su equipo quiere usar otra biblioteca).

    Si usted no comparte el .archivo de proyecto, entonces no es posible importar el proyecto con Eclipse. Usted tendrá que crear un nuevo proyecto con el asistente de proyectos en primer lugar, y entonces usted puede elegir importar «General->Sistema de Archivos», esto copiará todos los archivos en su espacio de trabajo. Esto probablemente no es lo que desea, porque significa que no se puede clonar el repositorio git en el área de trabajo, debe clonarlo en otro lugar y, a continuación, importar desde allí. Por lo tanto, siempre se debe compartir la .archivo de proyecto.

    Por favor deje un elogio si usted tiene sugerencias para esta explicación, o si usted no está de acuerdo con ella. Espero que esta ayuda el uno o el otro.

    • Con maven y m2e, es incluso necesario compartir la .proyecto?
    • Muy útil la instrucción. Yo estaba confundido ¿por qué todos los gitignore archivo include .proyecto. Pero después de su instrucción, me decido a compartir .proyecto.
  4. 4

    El área de trabajo de metadatos realmente no debería ser mantenido en control de código fuente. Los básicos de configuración del espacio de trabajo puede ser compartida a través de una equipo de proyecto.

    • Gracias, se ve prometedor. Voy a intentar que fuera.
    • Un proyecto de archivo de conjunto incluye lo que los proyectos deben ser controlados, y de donde, pero nada más. No es que yo estoy en desacuerdo con usted, creo que la forma más prudente de trabajo es comprobar en el código y por metadatos del proyecto, y salir de las áreas de trabajo bajo control local – pero si el OP insiste en compartir la configuración del espacio de trabajo, es probable que necesite más de un PSF.
    • Tom es correcto, que no funcionó para mí. El PSF contiene referencias a (un mal configurado y que no existe) repositorio de CVS, a la que no se puede conectar, por supuesto.
  5. 4

    Me mantengan .proyecto y .ruta de clases, no sólo son seguros para git, pero útil.

    .y de clase .los ajustes son en mi gitignore. Estos se generan y persona específica, respectivamente.

    • Parece que está a la derecha con esta afirmación, pero me pregunto por qué el github eclipse ignorar el archivo todavía contiene .proyecto y .classpath
    • El github eclipse ignorar no contienen .proyecto (a partir de ahora, al menos), sólo .cproject.

Dejar respuesta

Please enter your comment!
Please enter your name here