Uso de Subversion con el Modelo Promocional

Question

en el momento en que el uso de Subversion para el control de código fuente, pero todas de la fusión de trabajo para nuestras entregas se realizan de forma manual.Lanzamos varias veces al año, por lo que la creación de una rama para cada versión.Todo el trabajo de las anteriores ramas deben hacer en las posteriores.Trabajar más tarde de las ramas no deben hacer en las anteriores (esto es, en nuestros contratos).Creo que este es conocido como el Modelo Promocional.

Creo que el siguiente diagrama ilustra mejor nuestro flujo de trabajo deseado, con ramas que se crea cuando se empieza a trabajar en una nueva versión, y los cambios que fluye de las anteriores ramas para más tarde.

|
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 una significativa del tronco?
• Sería automatizado de combinación de trabajo de seguimiento de las actualizaciones de versiones anteriores de ramas para más tarde?
• Sería aceptar para cerrar/borrar/ignorar una rama (en este ejemplo la liberación de la rama 'a') sin reintegrar?
• Sería aceptar para crear la característica de las ramas de cada versión de la rama, y de combinación de trabajo de seguimiento para estos?(Iban a seguir las recomendaciones crear/fusionar/reintegrar el modelo).

Editar - agregar más información.

La razón por la que el tradicional Inestable Tronco modelo podría no ser adecuado se ilustra en el siguiente diagrama.Las características de cada lanzamiento no son necesariamente completado en orden de liberación (algunos clientes puede ser lento para confirmar los requisitos).Queremos propagar los cambios de las anteriores ramas más tarde, tan pronto como sea posible.

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

En este caso, queremos que la función 2 (completado en una rama de una) en la rama b, pero como este es un hijo a padre de mezcla, y por lo tanto no se admite por parte de la Subversión, se tendrá que hacer manualmente.Del mismo modo, cuentan con 6 habría que mezclar manualmente dos veces.Espero que esto sea relativamente lento y propenso a errores de proceso en comparación con rastreados funde.

Answer 1

Si entiendo tu situación, no hay nada en sus requisitos que hacen las cosas tan complejo como parece estar haciendo.También estás poniendo demasiado énfasis en los méritos de automática vsmanual de fusión (más sobre esto más adelante).CVS ramas hubiera sido otra cosa, pero no con la forma en SVN se encarga de "ramas" (es decir, no).

Usted podría tener un primario (inestable o estable) línea de desarrollo y crear sucursales por cada cliente o liberación (o ambos).Como características son validados, o bien se combinan de nuevo a la línea principal para que después las ramas pueden incluir los cambios o siempre combinar unidireccionalmente desde la oficina matriz.Nada de lo que usted requiere para cerrar la sucursal y la combinación no es menos automatizado que habría sido para apoyar a su primer (caótico) diagrama dado que hay simultáneas con múltiples líneas de desarrollo.

El requisito de que sólo se mezcla adelante suena como usted necesidad justa de combinar subconjunto de las revisiones de la línea principal, revisiones después de una rama determinada de la revisión.Haciendo su fusiona de esta manera te permitirá combinar los cambios de arbitrario ramas de vuelta a la línea principal tan a menudo como te gusta (como se confirmó con sus clientes) y puede ser aplicado hacia adelante con la confianza de que sólo se validan los cambios se apliquen.Puede configurar automática de la fusión a la pista de que la revisión de la copia (ver --stop-on-copia y rango basado funde).La liberación de las ramas, a continuación, recoger los conjuntos de confirmado los cambios que se han producido a partir de un determinado punto en adelante.

SVN no "pista combina" más de lo que soporta las ramas (que no sólo son de peso ligero copias).Que lo dices (o svnmerge dice) rangos de mezcla y aplica los cambios.Usted puede obtener el efecto que usted está contractualmente obligado a admitir, independientemente.

Para responder a sus preguntas:

• No creo que el modelo propuesto es muy eficaz.Por el contrario, ha aumentado el potencial para la función de seguimiento de caos como usted puede tener que escanear las ramas de los cambios de mezcla y hacia adelante varias veces.Por otra parte, no hay duda de confundir a los desarrolladores familiarizados con SVN y más tradicional SVN estructuras organizativas.

• Seguro.Que debe ser bastante independiente de la estructura que eligió demasiado.Vas a necesitar/querer seguir la pista de su revisión de los puntos a pesar de todo (tal vez a través de unos simples secuencias de comandos en el peor).

• Seguro.Las ramas tienen ningún costo en el SVN en el lado del servidor.El cliente tiene un costo si no toda la raíz de las cajas, pero que generalmente es un tonto cosa que hacer independientemente.Del mismo modo, no hay ningún problema ignorando o eliminación de una rama.Es sólo otro cambio a la revisión global de la jerarquía como cualquier otro copiar/borrar/renombrar/etc.

• Que deben trabajar independientemente de la "ramificación" de la estructura organizacional poner en su lugar.Suena como que hay tal vez un poco de malentendido sobre lo que significa ser una "sucursal" en el SVN.Usted debe ser capaz de establecer lo que se desea y realizar el 'manual' se fusiona con relativa facilidad independientemente y luego configuración automática de la fusión después de un par de actualizaciones de cliente para entender sus combinar pasos un poco mejor.

Saludos!

Answer 2

Usted dice:

  

Todo el trabajo de las anteriores ramas obligada   hacerlo en los posteriores. Trabajar en adelante   ramas no deben hacerlo en principios   queridos (esto es en nuestros contratos)

A continuación, si sustituimos las ramas en las liberaciones (dudo que sus clientes saben o se preocupan por "ramas"), obtenemos:

  

Todo el trabajo de las anteriores comunicados de mosto   hacerlo en los posteriores. Trabajar en adelante   comunicados no deben hacerlo en principios   queridos (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 "inestable tronco" del desarrollo. O tienes más requisitos que no nos ha dicho sobre, o se encuentra sobre-ingeniería.