Etiquetado de un checkout SVN con externos en las ramas de desarrollo

Question

La mayoría de nuestros proyectos utilizan muchos códigos comunes. Estamos (finalmente) avanzando hacia un sistema en el que estamos administrando ese código compartido de manera uniforme. Tratamos el código compartido como un proyecto separado en SVN, luego lo referenciamos como un externo. Sin embargo, tendemos a apuntar las bibliotecas externas a las ramas de desarrollo o incluso al tronco mientras el proyecto está en desarrollo, debido a los inevitables errores de portar las bibliotecas de un uso a otro.

Como resultado, hemos estado cometiendo errores al etiquetar archivos para publicación o hitos internos. De vez en cuando etiquetaremos un proyecto sin asegurarnos de que todos los elementos externos hayan sido etiquetados primero. ¿Cómo podemos resolver este problema? Estoy buscando formas de reducir la posibilidad de un error o recuperar/reparar después de hacer una etiqueta descuidada como esta. Idealmente, la solución sería una forma de hacer que SVN aplique la política actual, pero estoy interesado en cualquier experiencia con problemas como este.

Answer 1

me gustaría utilizar dos estrategias para hacer frente a ese problema

1. automatizar el etiquetado. Cree un script de shell que cambie todos los svn: externals a una etiqueta de revisión/lanzamiento fija antes de crear la etiqueta en el proyecto.
2. tienen una secuencia de comandos que comprueba la coherencia de las etiquetas existentes. En realidad, es posible reconstruir el estado en el momento del etiquetado incluso cuando el enlace externo está en el enlace troncal: como sabe la fecha y la hora en que se creó, también puede averiguar qué revisión de troncales estaba activa en ese punto y modificar el externo para apuntar a una revisión específica del enlace troncal, o al lanzamiento que estaba vigente en el momento en que se realizó la etiqueta.

Además, también puede obtener un gancho precompromiso que verifica si se está creando una etiqueta, y si todas las externas apuntan a revisiones fijas, rechazando la confirmación si este no es el caso.

Answer 2

Suena trillado, pero seguramente lo mejor que se puede hacer es no hacer referencia a las ramas de desarrollo de las bibliotecas. No haría eso si fuera una biblioteca de terceros, y tampoco es una buena idea hacerlo con sus propias bibliotecas.

Parece ser más trabajo, pero si encuentra un error en una biblioteca a la que se hace referencia, corríjalo, etiquete una nueva versión y haga referencia a esa nueva etiqueta en su proyecto.

Si realmente debe hacer referencia a las ramas de desarrollo de las bibliotecas, podría usar un script de enlace precompuesto que determine cuándo está haciendo una etiqueta y asegure que todas las externalidades a las que se hace referencia también son versiones etiquetadas: entonces la secuencia de comandos puede cometer si ese no es el caso. Sin embargo, es un gran golpe tomar cada vez que haces un commit.

Answer 3

También queremos aplicar la política de congelación de elementos externos que se copian en etiquetas, pero que aún no se han implementado del todo en el servidor.

La idea es que el gancho de precompromiso use el comando svnlook con el número de transacción para buscar cualquier destino "etiquetas /" en una copia. En caso de golpe, las propiedades deben ser examinadas y buscadas por svn:externals. Posiblemente otras propiedades para permitir una anulación de la política.

La pregunta obvia es la carga en el servidor y qué idioma usar para ese enganche. Normalmente SVN viene con mejores enlaces Python Ctypes, desafortunadamente la última vez que lo revisé no estaba disponible para Windows (ni compilable como es para este objetivo). Pero el módulo pysvn podría tener justo lo suficiente para hacer eso. Aparte de este lenguaje, los scripts bash podrían funcionar, pero serían desordenados y no tan portátiles. O puro C ...

Answer 4

mientras no trata sus bibliotecas internas como las externas? Si usa Apache Ivy (o Maven), sería bastante fácil publicar sus bibliotecas en un repositorio central (con un número de versión, 1.0 o SNAPSHOT_20091005) e importarlas usando el mecanismo estándar Ivy (o Maven).

De esta manera, elimina todos los problemas con SVN externos. Por supuesto, cada proyecto deberá usar etiquetas antes de crear una versión, pero esa es la "versión 101".

Answer 5

Estoy de acuerdo con Martin v. Löwis, pero pensé que señalaría que si solo codifica un número de revisión en su svn: externals, está pidiendo problemas si sus externos también definen su propio svn: externals!

En su caso, no le conviene ir y establecer un troncales de desarrollo externos a una revisión especificada, ya que esto bloquearía sus repos de desarrollo. Tampoco puedes ignorar las externalidades recursivas. La mejor opción es etiquetar recursivamente todos los elementos externos, esto permite que el desarrollo continúe, pero usted forma su propia etiqueta/rama para TODO.

Tengo un script que hace esto sino que limpiarlo un poco antes de lo pongo :)

Answer 6

Subversion versión de cliente 1.9 tiene una opción para --pin-externalssvn copy que parece que va a hacer exactamente lo que se quiere aquí.

Gracias a danielsh (Daniel Shahaf) en freenode IRC canal #svn para esta respuesta.