Subversion y dependencias

Question

Estoy tratando de encontrar una estrategia viable para un siguiente problema.

Tenemos varios proyectos web que dependen de nuestro marco. Todo está almacenado en nuestro SVN y tiene su propio proyecto con toda la estructura de directorios necesaria (troncales, etiquetas, ramas). En un ejemplo, tenemos proyectos webprj01 y webprj02 y tenemos un marco frm01. Todos ellos tienen estructura de proyecto SVN habitual: tronco, etiquetas, ramas.

webprj01 y webprj01 dependen de frm01 y en la vida real frm01 está presente como subdirectorio de webprj01 y webprj02. Para lograr esto en SVN, es posible establecer svn: propiedad externa y podemos configurar frm01 para apuntar a/frm01/trunk dentro de trunk de webprj01 y webprj02.

Para hacer una codificación de la vida real tenemos que tener los tres proyectos desprotegidos como una copia de trabajo y hacer los cambios a la base de código particular en su propia copia de trabajo. No hay forma de publicar cambios de webprj01/frm01 al SVN. El cambio debe hacerse en copia de trabajo frm01 y transferirse a través de SVN a copias de trabajo webprj01/frm01 y webprj02/frm01.

Esta solución tiene un problema con las dependencias durante la bifurcación. Realizo una rama de producción desde SVN/webprj01/trunk a /webprj01/branches/release-1.0.0. En dos días, mientras trabajaba en el segundo proyecto webprj02 y frm01, ya no puedo tener un checkout estable como a través de svn: external en branch release-1.0.0. El directorio frm01 ya apunta a nuevos cambios de frm01/trunk.

Descrito es solo una versión simplificada del problema. En nuestras situaciones de la vida real, las dependencias van a veces a cinco niveles de profundidad. Me gustaría poder obtener un código estable de SVN en cualquier momento. En diferentes palabras Cuando ramifiqué/etiqueté webprj01 como release-1.0.0. Quiero obtener un código estable para esa etiqueta en particular en un año desde la creación.

Es obvio que la estrategia descrita usando svn: externals no hace el trabajo. ¿Cuál sería tu experiencia con esta situación? No es necesario usar un solo pago. Incluso el uso de scripts de compilación u otra solución sería de ayuda aquí. Estoy buscando una solución a largo plazo al problema que no dependería en gran medida de las acciones humanas ya que somos propensos a cometer errores.

Answer 1

En el mundo de Java, no intentaría resolver esto utilizando solo un sistema de control de versiones; en su lugar, usaría una herramienta de administración de dependencias como Maven + un sistema de control de versiones.

En el lugar donde trabajo, tenemos una puesta a punto que parece bastante común:

Cualquier proyecto "marco" vive en su propia estructura de directorios (tronco, etiquetas, ramas) como que ya parecen tener . Estos también se administran usando Maven y cada vez que se ingresa algo, se publica una nueva versión del componente (en la mayoría de los casos, un archivo JAR) en nuestra reposición local de Maven (que reside en un servidor Nexus).

Cualquier proyecto que necesite utilizar el proyecto "framework" tendrá una dependencia hacia una versión específica del proyecto de framework - Maven automáticamente extrae esta versión del servidor Nexus cada vez que se construye el proyecto.

Esto nos permite liberar cada proyecto y componente de marco por separado, pero aún así realizar un seguimiento de las dependencias entre ellos. Incluso podemos tener múltiples versiones de los componentes de framework usados ​​por diferentes proyectos sin perder completamente la pista de las dependencias.

Hasta ahora esto ha funcionado muy bien para nosotros - sólo puedo ver dos inconvenientes:

se necesita un tiempo de puesta a punto, especialmente si usted no ha utilizado Maven antes.

Hay cierta sobrecarga al liberar cada proyecto, ya que también desea liberar cada componente dependiente para evitar tener dependencias con la versión "troncal" de otros componentes (es decir, la versión "SNAPSHOT" en la terminología de Maven).

Answer 2

Erik tiene razón, un administrador de dependencias lo ayudará, es posible que desee examinar a maven o ant/ivy.

Usar svn: externals como administrador de dependencias de un hombre pobre es un truco y requiere mucha disciplina: es un PITA averiguar qué versión de un marco está incluido, y luego algún comodín va a establecer la referencia externa en un proyecto para el tronco del framework y tendrás un tiempo realmente difícil para descifrar el delta entre lanzamientos.

En el pasado he tenido js, ​​css & xsl comunes a muchos proyectos empaquetados como archivos .tgz y publicados en un repositorio ivy por simples scripts ant, luego los proyectos tienen compilaciones ant (y archivos ivy.xml) que resolver las dependencias y luego empacar todo. Funcionó, pero

• chicos Cliente web tuvo problemas con control de código fuente, y mucho menos la gestión de la dependencia. Fue realmente difícil hacer que "entendieran" lo suficiente como para publicar los cambios en un módulo común en un repositorio local y luego construir un proyecto que dependiera de él para ver sus cambios.

• El paso extra que mencionó Erik, teniendo que liberar múltiples artefactos para obtener algo listo para la producción.

• Cruddy legacy design significó la mayoría de los cambios donde en realidad en el código común, 1 de cada 10 lanzamientos de la versión desplegable realmente tenía cambios en su código ... usualmente estaba en el código común incluido.

seriously - svn: Externals como una gestión de la dependencia va a llegar a ser un dolor de cabeza. Vale la pena la inversión. Habiendo dicho que estos muchachos tenían problemas con la gestión de la dependencia, sería mucho menos probable, así que ordena los svn: externos en muchas ramas que estás teniendo ahora.

Si tuviera que hacer eso una vez más - I'd go maven.