¿Cómo maneja múltiples ramas de lanzamiento en subversión?

Question

En la empresa para la que trabajo utilizamos Subversion y TortoiseSVN para administrar nuestro código fuente. Cada proyecto se bifurca del tronco. Cuando necesitamos integrar los diferentes proyectos para un lanzamiento, creamos una rama de lanzamiento que contiene el código que se integrará, probará e implementará en la producción. Normalmente, solo tenemos una rama de publicación.

Recientemente, sin embargo, algunos de los artículos en uno de los proyectos se retrasaron y estaban programados para el próximo lanzamiento. Como resultado, alguien solicitó que se creara una segunda rama de publicación para mantener los cambios retrasados ​​y evitar que se fusionen en la versión actual.

Hasta ahora, esto nos ha causado mucha pena y muchos conflictos de árbol, ya que algunos elementos de la rama de versiones futuras dependen de los elementos de la rama de la versión actual. La única forma en que pudimos resolver estos problemas fue esperar hasta que se implementó la versión actual, fusionar la rama de lanzamiento en el tronco, fusionar el tronco en la rama de lanzamiento futura y luego fusionar los cambios de la rama de proyecto en la futura rama de lanzamiento .

Como resultado de este problema, hemos tenido que recomendar que nunca deberíamos tener más de una rama de publicación porque causa problemas de combinación.

Sin embargo, me pregunto si este es el camino correcto a seguir. ¿Alguien sabe si es posible administrar múltiples ramas de publicación en subversión? Sin duda, debe ser posible administrar las funciones que se retrasan sin comprometer la capacidad de fusión.

¿Alguien tiene alguna experiencia con respecto al escenario que he presentado y que estaría dispuesto a compartir? Solo me gustaría saber cómo puedo mejorar la forma en que se administran las versiones en mi lugar de trabajo para que esto no vuelva a suceder.

Answer 1

Para ser sincero, no estoy del todo seguro de cómo funciona su sistema a partir de la descripción. Sin embargo, he tenido que administrar proyectos con varias versiones en vivo en el pasado. La forma en que lo hicimos fue:

1. No se libera nada que no esté primero en la línea externa.
2. Cada versión tiene su propia rama de versión.
3. La única forma de actualizar una rama de versión es fusionar desde el enlace troncal.

De esta forma podríamos elegir qué características eran en qué versión. Al usar Merge-Tracking, también nos permitió crear una página web que nos mostró gráficamente qué fue donde.

Lo más importante es tener una rama totalmente integrada que pueda elegir: esta es mi definición de maletero.

Este no es un sistema perfecto. Si omitía las versiones, las dependencias dificultaban las cosas, y realmente necesitábamos lo gráfico para mostrarnos dónde estaba, pero en general parecía funcionar bien.

Ver también mi respuesta here.

Answer 2

Esto no es donde sobresale la tortuga. Para hacer complicados escenarios de fusiones y sucursales necesita algo como clearcase config spec para hacer su control de versiones.

Si usa tortuga, es mejor que mantenga el tronco como tal, y luego ejecute la integración continua en el tronco o cree ramas para cada característica, fusionándolas cuando se complete el desarrollo de características. Si haces esto, entonces solo tendrás código en el tronco que se prueba. Luego eliges un punto de lanzamiento, haces tu integración y traes las correcciones necesarias a tu troncal, pero también permites que tus equipos continúen su desarrollo.

Answer 3

Creo que desea fusionar el seguimiento, ya sea a través de svnmerge.py, o mediante el seguimiento de combinación integrado de Subversion 1.5. Esto le permite bloquear ciertos cambios para que no se fusionen en una sucursal, lo que luego podría hacerse con todos los cambios relacionados con las funciones que solo desea incorporar a la próxima versión.

Answer 4

Casi siempre querrá que los cambios en la primera rama retrasada estén presentes en la segunda. Por lo tanto, la segunda rama de publicación se debe realizar desde la primera rama de publicación, y los cambios desde la primera deberían fusionarse periódicamente. Idealmente por las mismas personas que los hicieron en primer lugar.

La bifurcación de Spepladder (?) Funcionará bien en este caso - simplemente abandone el tronco y trepe.

Answer 5

Mi empresa ha tenido problemas similares.

Tuvimos un proyecto retrasar una versión, la llamaremos 2.0, por varios meses. Mientras tanto, teníamos problemas de producción en la rama actual, llamémoslo 1.5, que justificaba más lanzamientos. No pudimos usar trunk, porque tenía las características embargadas, así que comenzamos a ramificarnos desde las sucursales. Nuestra versión 1.6 se ramificó de 1.5, no de tronco. Además de nombrar la convención, la versión 1.6 no es más que 1.5.1. Como esto no es un SOP, hemos tenido mucho cuidado de documentar lo que estamos haciendo.

Y no estoy esperando el punto de fusión, donde finalmente unimos la rama 1.6 y 2.0. No podemos fusionar los cambios en 1.6 de nuevo en trunk o 2.0, porque eso solo empeora el control de calidad en los problemas 2.0. Estamos ejecutando Subversion 1.4.6, por lo que no hay ayuda del software; todo será una fusión manual.