¿Cuál es la mejor manera de manejar ramas de sucursales de proveedores en SVN?

Question

Por lo tanto, ya estoy familiarizado con esto:
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html

Mi pregunta es ¿cómo manejar una rama de proveedor que tiene tanto una versión estable y una rama de alfa/beta que desea integrar?

Por lo tanto, supongamos que sigue el ejemplo original del libro SVN. Tendrías:

svn: // localhost/home/svn/vendedor/libcomplex/corriente
SVN: //localhost/home/svn/vendor/libcomplex/1.0
svn: // localhost/home /svn/vendor/libcomplex/1.1 (igual que el actual)

Ahora, supongamos que tiene dos versiones de su propia 'calc' aplicación:

Calc (esto es esencialmente tronco == Calc 2.0)
Calc -1.0 (lanzado al público)

Digamos que calc-1.0 usa libcomplex 1.0 y calc (en el tronco) utilizan libcomplex 1.1, que aún se está desarrollando.

Hay un error en libcomplex 1.0 y se lanza una nueva versión para corregir ese error: libcomplex 1.0.1. Los mantenedores libcomplex también han incluido esta corrección de error en libcomplex 1.1.

No está listo para lanzar Calc 2.0, por lo que necesita integrar libcomplex 1.0.1 en su sucursal de proveedor y luego actualizar calc-1.0 para hacer una versión de corrección de errores.

¿A dónde va?

No puede ponerlo en svn: // localhost/home/svn/vendor/libcomplex/current porque 1.1 vive actualmente allí.

¿Copias svn: //localhost/home/svn/vendor/libcomplex/1.0 a svn: //localhost/home/svn/vendor/libcomplex/1.0.1 y luego traes la nueva versión? De esta forma, puede usar svn para fusionar la diferencia entre 1.0 y 1.0.1 con calc-1.0.

Answer 1

La práctica recomendada es crear una rama para su lanzamiento. De esta forma, no importa qué cambios realice en el tronco de las carpetas de proveedores. A continuación, puede actualizar la rama de versión 1.0 con la versión 1.0.1 de libcomplex, y eso no habría afectado al enlace troncal (calc 2.0).

Esto no funcionará si calc 1.0 y calc 2.0 viven lado a lado en la misma rama, sin embargo.

Lo siguiente es no tener "corriente". Simplemente consulte directamente la versión que está utilizando. por ejemplo, dejar la estructura de carpetas como:

vendor/libcomplex/1.0 
vendor/libcomplex/1.1 
vendor/libcomplex/1.0.1 

y no sobreescribir en estos archivos. Entonces, calc 2.0 puede hacer referencia a la versión 1.1 de libcomplex, y calc 1.0 puede referirse a 1.0.1.

Su última opción, (y no realmente recomendada), es usar etiquetas svn (ver complex tags). Le permiten mezclar y combinar versiones, por lo que técnicamente podría crear una etiqueta para representar el lanzamiento del parche de su calc 1.0 con la versión anterior de libcomplex.

Answer 2

La idea detrás de las sucursales de los proveedores parece ser que deberían reflejar lo que podría ser el repositorio del proveedor.Por lo tanto, current representa el tronco del proveedor, y las versiones etiquetadas representan las propias etiquetas del proveedor, creadas cuando se lanza cada versión.

Dado esto, la respuesta a la pregunta es bastante clara. Para haber lanzado 1.0, 1.1 y luego 1.0.1, el proveedor presumiblemente tiene una rama para las versiones corregidas de errores 1.0.x mientras continúa trabajando en las versiones 1.1 y posteriores en su troncal. Nuestra sucursal de proveedor debe reflejar esta configuración.

Es decir, también necesitamos una rama (dentro de nuestra rama de proveedores) para las versiones corregidas de errores 1.0.x. Esto debería crearse a partir de la corriente en el momento en que contenía 1.0, y puede llamarse algo así como current-1.0.x. Esta rama se puede actualizar para mantener 1.0.1, que luego se puede etiquetar y copiar en nuestro propio árbol, como de costumbre.

Answer 3

Yo trabajo como este con bibliotecas externas:

project/myProject/{branches,trunk} 
vendor/libcomplex/1.0 
vendor/libcomplex/1.0.1 
vendor/libcomplex/2.0.0 
mypatched-vendor/libcomplex/1.0 
mypatched-vendor/libcomplex/1.0.1 
mypatched-vendor/libcomplex/2.0.0 

Dónde está vendor/<lib>/<version> nunca cambió después de la importación y proveedores mypatched se inicia con svn cp vendor/<lib>/<version> mypatched-vendor/<lib>/<version>.

Ahora la diferencia de vendor/libcomplex/1.0 mypatched-vendor/libcomplex/1.0 debería darle parches para combinar con la recién importada versión 1.0.1.

Probablemente soy una minoría, pero me gustan las propiedades svn:externals. A muchos IDEs no les gustan, así que úselos con discreción. El motivo es esto Ahora puedo editar mi proyecto principal:

checkout project/myProject/trunk to myprj-trunk en su salida.

svn propedit svn:externals . 
# with 
libcomplex URLTO/mypatched-vendor/libcomplex/1.0 

Cuando quiero probar una nueva versión de lib simplemente edito esa propiedad a otro lugar y ejecuto la actualización. Esto también tiene el efecto de que no comprometo accidentalmente nada a la parte de libcomplex del árbol, incluso si he cambiado algunos archivos en WC. Tengo que estar bajo ese directorio o especialmente comprometer cambios allí.

Ahora la actualización, las correcciones, las ramas de mi proyecto se mueven fácilmente a las nuevas versiones de libcomplex sin más que la combinación inicial de mypathed-vendor. Todas las ramas de mi proyecto solo necesitan propchange y testing. También es relativamente fácil obtener dependencias de la biblioteca para mis proyectos en mi humilde opinión.

Lo último agradable de las externalidades es que cuando se inicia un nuevo proyecto y la versión anterior también está muy desarrollada y utiliza svn, puede hacer una referencia de subida como externa si no necesita parchear esa biblioteca. Y cuando se rompe aguas arriba de su proyecto puede mantener la versión principal por un tiempo con opciones -rNUM como:

libcomplex -r21 UPSTREAMURLTO/mypatched-vendor/libcomplex/trunk 

Una desventaja definitiva a svn: externals es que la url externo tiene que ser accesible con el mismo URI de todo pago y envío variantes de tu proyecto

Pero el uso externo permite a su proveedor para mantener cesión temporal a parte de su proyecto de recompra.