Usando Subversion con el modelo promocional

Question

en el momento en que usamos Subversion para el control de código fuente, pero todo el trabajo de fusión para nuestras versiones se realiza manualmente. Lanzamos varias veces al año, así que crea una rama para cada lanzamiento. Todo el trabajo de las ramas anteriores debe llegar a los posteriores. El trabajo en las sucursales posteriores no debe pasar a las anteriores (esto es en nuestros contratos). Creo que esto se conoce como el Modelo Promocional.

Creo que el siguiente diagrama ilustra mejor nuestro flujo de trabajo deseado, con ramas que se crean cada vez que el trabajo comienza en una nueva versión y cambios que van de las ramas anteriores a las posteriores.

 
| 
1 
| 
|\ 
| \ 
| 2 
3 | 
|\| 
4 | 
| |\ 
5 | \ 
| 6 | 
| | 7 
|\|\| 
| |\| 
8 9 |\ 
| | | \ 
|\| | 10 
x |\| | 
    | |\| 
    | | | 

a b c d 

• ¿Sería este modelo de trabajo sin problemas usando Subversion a pesar de la falta de un tronco significativa?
• ¿El seguimiento de fusión automatizado funcionaría para las actualizaciones de las sucursales anteriores a las posteriores?
• ¿Sería correcto cerrar/eliminar/ignorar una rama (en este ejemplo, liberar la rama 'a') sin reintegrar?
• ¿Sería correcto crear ramas de características fuera de cada rama de release, y uniría el trabajo de seguimiento para estas? (Seguirían el modelo de creación/fusión/reintegración recomendado).

Editar - añadir más información.

El siguiente diagrama ilustra el motivo por el que el modelo de Troncal inestable tradicional podría no ser adecuado. Las características para cada versión no se completan necesariamente en orden de lanzamiento (algunos clientes pueden tardar en confirmar los requisitos). Queremos propagar los cambios de las ramas anteriores a las posteriores tan pronto como sea posible.

 
    a 
    | 
    1 
    | 
    b|\ a 
    | \ 
    | 2 
    3 | 
    | | 
    4 | 
    b/|c | 
/5 | 
| | 6 
7 | | 
b c a 

En este caso, queremos característica 2 (terminado en rama a) en la rama B, pero como esto es una fusión de niño a los padres, y por lo tanto no es compatible con la subversión, que tendrá que ser hecho a mano. Del mismo modo, la característica 6 debería fusionarse manualmente dos veces. Anticipo que se trata de un proceso relativamente lento y propenso a errores en comparación con las fusiones de seguimiento automático.

Answer 1

Si entiendo su situación, no hay nada en sus requisitos que haga las cosas tan complejas como parece que las está haciendo. También está poniendo demasiado énfasis en los méritos de la fusión automática frente a la manual (más sobre esto más adelante). Las ramas de CVS habrían sido otra cuestión, pero no con la forma en que SVN maneja las "ramas" (es decir, no lo hace).

Puede tener una línea de desarrollo primaria (inestable o estable) y crear ramas para cada cliente o versión (o ambas). A medida que se validan las características, o bien se fusionan a la línea principal para que las ramas posteriores puedan incluir esos cambios o siempre se fusiona unidireccionalmente desde una rama principal. Nada requiere que cierre la sucursal y la fusión no está menos automatizada de lo que hubiera sido para respaldar su primer diagrama (caótico) dado que tiene múltiples líneas de desarrollo concurrentes.

El requisito de que solo se fusionen hacia adelante parece que solo necesita fusionar revisiones de subconjuntos desde la línea principal, revisiones después de una revisión de rama determinada. Hacer las fusiones de esta manera le permitirá fusionar los cambios de las sucursales arbitrarias a la línea principal con la frecuencia que desee (tal como se confirman con sus clientes) y se puede aplicar con la confianza de que solo se aplican los cambios validados. Puede configurar la fusión automática para rastrear esa revisión de copia (consulte fusiones basadas en rango y en pausa). Suelte las ramas y luego recoja los conjuntos de cambios confirmados que han ocurrido desde un punto dado hacia adelante.

SVN no "rastrea fusiones" más de lo que admite ramas (que no es así, son simplemente copias livianas). Usted le dice (o svnmerge lo dice) que se fusiona y aplica esos cambios. Puede obtener el efecto que, contractualmente, se requiere que soporte, independientemente.

para responder a sus preguntas planteadas:

• No creo que el modelo propuesto es que muy eficaz. Por el contrario, tiene un mayor potencial para el caos de seguimiento de características, ya que es posible que tenga que escanear las sucursales en busca de cambios y fusionarse varias veces. Además, sin duda confundirá a los desarrolladores familiarizados con SVN y las estructuras organizativas de SVN más tradicionales.

• Sure. Eso debería ser bastante independiente de la estructura que elijas también. Necesitarás/quiero hacer un seguimiento de tus puntos de revisión independientemente (tal vez a través de algunos scripts simples en el peor).

• Sure. Las sucursales no tienen ningún costo en SVN en el lado del servidor. El lado del cliente tiene un costo si haces los arreglos de raíz completos, pero eso es generalmente una tontería que hacer independientemente. Del mismo modo, no hay problema para ignorar/eliminar una rama. Es solo otro cambio a la jerarquía de revisión global como cualquier otra copia/eliminación/cambio de nombre/etc.

• Eso debería funcionar independientemente de la estructura organizativa "ramificada" establecida. Parece que hay un poco de malentendido sobre lo que significa ser una "sucursal" en SVN. Debería poder configurar lo que desee y realizar fusiones "manuales" con relativa facilidad independientemente y luego establecer la fusión automática después de algunas actualizaciones de clientes para que pueda entender mejor los pasos de su fusión.

¡Salud!

Answer 2

Usted dice:

Todo el trabajo de las ramas anteriores debe hacerlo en los posteriores. Trabajan en posteriores ramas no deben hacerlo en anteriores los (esto es en nuestros contratos)

Aquí, si sustituimos ramas con comunicados (dudo que sus clientes saben o se preocupan por "ramas"), obtenemos :

Todo el trabajo de las versiones anteriores debe hacerlo en las posteriores. Trabajan en posteriores comunicados no se deben hacer en los anteriores (esto es en nuestros contratos)

no veo nada en ese requisito para sugerir el esquema de ramificación muy complejo que está proponiendo - usted puede hacer esto con el estilo clásico de desarrollo "tronco inestable". O tiene más requisitos de los que no nos ha informado, o está sobre-ingeniería.