plugin - Cómo distribuir carpetas localmente y en SVN cuando se usa eclipse

svn connector eclipse oxygen

Question

He trabajado con eclipse y SVN durante muchos años en equipos de un solo desarrollador hasta 12 y siempre fui yo quien configuró la estructura de mi carpeta. Logré que funcionara de alguna manera, pero creo que el diseño de mi carpeta dista mucho de ser óptimo. Es difícil decir cuál era mi diseño de carpeta típico, porque cada vez se veía muy diferente.

Ahora estoy empezando otro gran proyecto, y quiero hacerlo de manera profesional esta vez.

Hechos sobre el proyecto

Esos son los hechos en este momento:

• Todos los desarrolladores trabajarán con Eclipse
• Algunos usarán Subclipse para integrar SVN en Eclipse, otros usarán clientes externos como Tortoise SVN o svnX.
• estamos desarrollando en Windows y Mac OS
• estamos usando hormiga para automatizar pruebas de construcción y junit
• habrá múltiples proyectos interrelacionados:
  • una biblioteca escrita en Java puro, por lo que se ejecuta en todas las plataformas Java conocidas
  • varias aplicaciones para varias plataformas de Java (J2SE, J2ME, Android ...). Todas esas aplicaciones dependen de la biblioteca mencionada anteriormente

¿Qué hacer con .project?

No estoy seguro de si cometer esos archivos generados por eclipse (como '''' .project '''' y '''' .classpath ''''). En proyectos anteriores, a veces los colocamos en el SVN, a veces no lo hacíamos, y ambos enfoques tenían sus pros y sus contras. Una vez, incluso comprometimos todo el espacio de trabajo, pero eso parecía ser una mala idea.

Un concepto clave que ciertamente me falta es cómo maneja Eclipse su espacio de trabajo. Por defecto, todo el proyecto se encuentra dentro de la carpeta de espacio de trabajo, pero puede haber proyectos que son externos, que están vinculados de alguna manera mágica que simplemente no entiendo.

Posibles diseños de carpeta

No estoy seguro de cómo diseñar el proyecto localmente y en el repositorio. Creo que hay tres posibilidades:

• el espacio de trabajo es una subcarpeta de mi copia de trabajo local (como c: / code / myWorkingCopies / projectXyz / trunk / workspace)
• mi espacio de trabajo ES mi copia de trabajo (yo uso c: / code / myWorkingCopies / projectXyz / trunk / as workspace)
• Mi espacio de trabajo está en algún lugar (c: / code / workspace) y mi copia de trabajo en otro lugar (c: / code / myWorkingCopies / projectXyz / trunk) y tengo esos proyectos externos
• cualquier otra idea?

¿Qué tipo de respuesta estoy buscando?

Una estructura de carpeta ficticia, tal vez algo así (¿acabo de responder mi propia pregunta?):

• el maletero
  • proyectos
    • proyectoA
    • proyecto B

Junto con una sugerencia de dónde pagar, dónde:

• checkout trunk / projects a c: / code ...)

Y algunas pautas como

• nunca cargue archivos de tipo x, y, z ...

Answer 1

Recientemente comencé a usar Subclipse y tengo un método que funciona para mí. Estamos trabajando con aplicaciones PHP, por lo que creo un nuevo proyecto SVN a través del asistente de proyectos de Eclipse, eligiendo ''Checkout Projects through SVN''. Luego configuro ese proyecto usando el asistente de configuración del proyecto y selecciono PHP como el tipo de proyecto. Nombro el proyecto para que en mi espacio de trabajo tenga el nombre del proyecto en el nivel superior del explorador del proyecto.

Nunca comprometo nada creado específicamente para Eclipse, especialmente porque no todos en nuestro equipo usan Eclipse. Eso significa excluir los archivos .project y cualquier otro archivo creado por Eclipse.

Un beneficio adicional de usar este método es que puede tener más de un repositorio revisado en el espacio de trabajo. Trabajamos con dos ubicaciones de repositorio para nuestro proyecto (por razones específicas en las que no voy a entrar), por lo que me resulta fácil y conveniente trabajar en ambos ''proyectos'' simultáneamente.

Estoy seguro de que hay otras maneras de hacerlo, pero esta es la forma más fácil de usar Subversion y Eclipse.

Answer 2

Tanto en Macromedia Dreamweaver como en Eclipse, he estado haciendo lo siguiente:

Working folder:
C:/Development/
/ProjectA
/ProjectB
/ProjectC

Cada proyecto tiene su propio repositorio, y cada pago es solo de / trunk /.

Nota: para Eclipse, no cree un proyecto de repositorio SVN, solo cree el proyecto "Aplicación Java" o "Aplicación PHP" como lo haría normalmente, y utilice un programa externo para realizar el pago en esa carpeta. Eclipse detectará automágicamente la información .svn y le permitirá usar las herramientas SVN, sin dejar de utilizar el espacio de trabajo adecuado.

Answer 3

Tenemos una configuración similar (usuarios de Mac, Linux y Windows) y nuestra estructura de carpetas es:

• el maletero
  • código
    • proyectoA
    • proyecto B

Comprobamos los archivos .project, .settings y .classpath, así como el código, pero NO los espacios de trabajo. Las trampas reales tienen que ver con la ruta de compilación. Si resuelve estos problemas, no hay dolor de cabeza ni requisitos sobre el directorio en el que se deben realizar las comprobaciones.

Algunos consejos:

1. Si sus proyectos se referencian entre sí, asegúrese de que se refieran entre sí mediante la pestaña "Proyectos" de la ruta de compilación. Esto mantendrá todas las referencias a otros proyectos relativas (../projectA en lugar de / opt / trunk / projectA que romperán los proyectos de otras personas).
2. Si tiene bibliotecas externas a las que hace referencia, cree bibliotecas de usuarios y haga que todos creen una con el mismo nombre. Usamos JBoss para que todos creen una biblioteca de usuario llamada JBoss que haga referencia a los archivos jar en su instalación local de JBoss. De esta forma, no importa dónde esté instalado JBoss, mientras tenga esa biblioteca de usuario, estará listo. Su proyecto hará referencia al nombre de la biblioteca del usuario, pero la información de la biblioteca del usuario real es local para cada usuario.
3. Asegúrese de que todos conozcan los consejos número 1 y 2. Las únicas veces que las cosas se arruinan aquí es cuando alguien se olvida de hacer referencias a través de la pestaña Proyecto en lugar de simplemente vincular directamente al contenedor.

Todo esto funciona con plugins Eclipse SVN o sin.

Answer 4

Yo uso, y recomiendo encarecidamente la estructura del repositorio algo así como:

• Proyectos
  • ProjectA
    • el maletero
      • Java
      • html
      • documentos
      • conf
• Vendedor
  • junit
    • corriente
    • 1.1
    • 1.2

En el disco usa un diseño como:

c:/dev/
/ProjectAtrunk/
/ProjectBbranch4/

Trabajando de esta forma, sus ramas y etiquetas están cerca de sus troncales y es poco probable que dependa de la estructura de los proyectos en su repositorio para hacer referencia a las bibliotecas externas. Todas las referencias al código fuera del tronco del proyecto deben usar elementos externos.

Todo esto significa que es más probable que sea capaz de mantener la máxima de que revisar el troncal es todo lo que necesita para poder construir su proyecto. El código compartido se guarda y gestiona como un proyecto separado y se hace referencia a los externos.

Puede ver los cambios en el tronco de un proyecto y ver un historial completo de su proyecto sin basura. Es menos probable que haya cambios en su proyecto que no son visibles cuando mira su historial de revisión en el tronco.

Cuando suelte, haga uso de ramas estables y svn-merge.

Answer 5

Los espacios de trabajo y los repositorios no deben estar relacionados.

El espacio de trabajo es realmente justo donde Eclipse almacena una gran cantidad de configuraciones. Los archivos de proyecto pueden (y normalmente lo hacen) vivir en el espacio de trabajo, pero como usted sabe, se pueden importar desde una fuente externa: la importación es solo un enlace lógico.

Puede crear tantos espacios de trabajo como desee para fines específicos; Incluso podría importar proyectos en un área de trabajo a otro si tenía motivos para hacerlo.

El diseño de SVN debe estar separado de cómo se define su espacio de trabajo. Pueden terminar pareciendo similares, pero eso no debería implicar que en realidad son lo mismo. Recomiendo que cada proyecto de Eclipse tenga su propio proyecto SVN, de modo que en lugar de tener

• http: // myrepo
  • myworkspace
    • el maletero
      • proyectoA
      • proyecto B
    • etiquetas
    • ramas

tienes

• http: // myrepo
  • proyectoA
    • el maletero
    • etiquetas
    • ramas
  • proyecto B
    • el maletero
    • etiquetas
    • ramas

Lo que esto hace por usted es darle la flexibilidad de diseñar su espacio de trabajo completamente separado de cómo está estructurado su repositorio. Podrá ver proyectos individuales en el área de trabajo sin tener que pagar la totalidad de la base de código. Podrá hacer que los proyectos se revisen en las ramas de desarrollo mientras que otros están en el enlace troncal, puede revertir los cambios en un proyecto y dejar otro solo, y así sucesivamente.

La última pregunta sobre qué artefactos registrar en SVN es una cuestión de gusto. Recomiendo comprobar los artefactos que sean universales en todo el equipo de desarrollo. Si Eclipse es el IDE estándar, siga adelante y compruebe los archivos .project y .classpath para que un nuevo desarrollador pueda realizar el pago y compilar inmediatamente. Si ciertos complementos son universales y tienen sus propios archivos de configuración, continúe y verifique también los mismos. Por otro lado, cualquier cosa que no se comparta con el equipo de desarrollo debe dejarse fuera del repositorio.

Espero que esto ayude.

EDITAR

La experiencia adicional me ha enseñado que lo único que debe pasar al control de la fuente son los archivos fuente reales. Los archivos de configuración y configuración deben ser regenerados por el desarrollador al configurar un nuevo proyecto.

Answer 6

Ickster dice "... pero como saben, se pueden importar desde una fuente externa; la importación es solo un enlace lógico".

En realidad, esto no es del todo cierto. Una importación realiza una copia, mientras que un recurso vinculado es un enlace a la estructura fuente externa. Ver: Recursos vinculados y Crear recursos vinculados