subversion - Componentes compartidos en todos los proyectos, ¿existe una mejor alternativa que svn: externals?

svn trunk

Question

Mi situación: tengo varios componentes, que a veces tienen cambios, y se comparten en muchos proyectos diferentes. Cada proyecto los pone en una subcarpeta llamada / depends. El depende tiene un montón de svn externos para todos nuestros componentes comunes.

svn: Externals me está causando mucho tiempo y dolor.

• Mostrar el registro en la carpeta raíz del proyecto no mostrará cambios para svn: carpetas externas (aunque la confirmación y la actualización son lo suficientemente divertidas, funcionará con svn: externals)
• Cuando se bifurca, los svn: externos no están ramificados.
• Debido a que no se bifurca en svn: externos, cualquier cambio generalmente rompe el tronco.
• Las etiquetas no congelan sus aspectos externos. Esto realmente frustra el propósito del etiquetado.

Recuerde que tengo varios proyectos (digamos 10 para esta discusión, cada uno usando los mismos externos), por lo que mantener directorios comprometidos normales para cada proyecto me costaría mucho tiempo de fusión.

¿Hay una mejor alternativa para mi situación?

Answer 1

Creo que parte del problema es que los ciclos de lanzamiento para los componentes compartidos no necesariamente coinciden con los ciclos de lanzamiento de los proyectos.

Los componentes compartidos como se describen aquí tienen su propio ciclo de publicación . En otras palabras, cada uno podría administrarse como un proyecto separado (o tal vez la colección de ellos administrada como un proyecto separado) con un número de versión / versión propio.

Tenga en cuenta que la definición de svn:externals puede incluir una revisión específica .

Esto permite que cada uno de los proyectos que hace uso de un componente compartido se desarrolle frente a una versión / revisión específica de ese componente compartido (o la colección de componentes compartidos), proporcionando un conjunto estable de dependencias para el proyecto. Los cambios en los componentes no romperán los proyectos porque cada proyecto está mirando una revisión específica de los componentes que no es necesariamente la HEAD en el trunk .

Si bien esto puede parecer más trabajo por adelantado, creo que a la larga esta práctica proporciona un mejor proceso de gestión del cambio para este tipo de situaciones.

Answer 2

Estoy de acuerdo con @Ken.

Recomiendo enfáticamente que no se use svn:externals sin una revisión específica. Sin una revisión, es imposible recrear los pagos antiguos. Si solo anclas tus externos al etiquetar, solo podrás recrear lo que has etiquetado. Si quieres recrear alguna revisión intermedia en trunk, estás solo.

Una razón para no ramificar externos es que no está claro cómo se debe hacer eso. Si sus elementos externos en el proyecto A apuntan a etiquetas / 2.0.0 y están creando una rama 3.4.x para su proyecto, ¿a qué debe referirse el componente externo A del proyecto? ¿Debe proyecto A rama también? Si es así, ¿a qué versión?

Si los proyectos tienen ciclos de liberación diferentes, en general es imposible definir un comportamiento razonable para los externos cuando se bifurcan.

(Es posible que desee echar un vistazo al script svncopy.pl si aún no lo ha hecho (incluido en la distribución de origen de Subversion) que le permite fijar elementos externos durante el etiquetado).

Hemos encontrado que svn: externals funciona muy mal cuando se usa para mantener juntos un conjunto de componentes que está desarrollando activamente. Externals funciona bien para incorporar componentes externos que no se mueven mucho y en los que no existe el problema de la bifurcación.

Answer 3

Podría intentar usar las denominadas ramas de proveedores:

http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.vendorbr

Es una estrategia útil cuando trabajas con bibliotecas de terceros, pero también puede ser útil en una situación como la tuya.

Answer 4

Dije esto en una pregunta similar: Debería usar svn:externals como referencias externas de diferentes repositorios. Entonces svn:externals debe referirse a componentes, módulos, herramientas de terceros, etc. que residen en diferentes repositorios.

No debe usar svn:externals para emular un comportamiento de "enlace simbólico" utilizando externalidades para apuntar al mismo repositorio.

Puede resolver estos problemas la mayor parte del tiempo modificando su estructura de construcción, o usar scripts de salida y función de pago disperso.

svn: los externos tienen muchos problemas, la mayoría de ellos son difíciles de ver, rastrear y reparar: vea un ejemplo aquí

• commits no puede abarcar más de lo externo (sin compromisos atómicos)
• las ramas no ramificarán sus externos
• las etiquetas no "congelarán" sus elementos externos, por lo que las últimas compilaciones pueden dar como resultado compilaciones diferentes / rotas
• fusión y reeintegración no funcionará en exteriores

Si usa externos para apuntar a otros repositorios, la mayoría de las veces no tendrá estos problemas.

Answer 5

svncopy.pl (mencionado en esta pregunta ) volverá a escribir las rutas en svn:externals a su nueva ubicación en la rama.