¿Cómo trabajo simultáneamente en la versión 1.1 y la versión 2.0?

Question

La situación:Se nos acabó la versión beta y la versión 1.0 se lanzó en varios sitios de clientes.El equipo A ya está ocupado trabajando en la versión 1.1 que tendrá correcciones de errores incrementales y ajustes de usabilidad, mientras que otro equipo trabaja en la versión 2.0 con cambios a gran escala, donde es posible que el núcleo del producto haya sido completamente rediseñado.Ahora, la mayoría de los cambios realizados en la versión 1.1 tendrán que llegar a la versión 2.0 en algún momento, y es posible que algunas de las correcciones de errores realizadas en la rama 2.0 deban programarse para una versión anterior.El problema es que dado que 2.0 tiene diferencias fundamentales, no se pueden fusionar cambios desde 1.1 sin una conversión manual, ni viceversa.

Mi pregunta:¿Cuáles son las mejores prácticas de control de revisiones para minimizar los conflictos de fusión y la duplicación del trabajo en este tipo de situación?¿Cómo puedo garantizar que mis equipos dediquen el menor tiempo y esfuerzo posible a problemas de control de revisiones y al mismo tiempo proporcionen parches regulares a los clientes?

Answer 1

Una buena manera es corregir cada error en la rama estable y fusionar la rama estable con la rama de desarrollo.Este es el Líneas paralelas de mantenimiento/desarrollo patrón, y la clave es fusionarse temprano y con frecuencia.Fusionarse con poca frecuencia y tarde significa que la rama de desarrollo es irreconocible en comparación con la estable, o que el error no se puede repetir de la misma manera.

Subversión incluye seguimiento de fusiones desde la versión 1.5 para garantizar que el mismo conjunto de cambios no se fusione dos veces, lo que provocará conflictos tontos.Existen otros sistemas (p. ej. git, Mercurial, Accurev, Forzosamente) que le permiten hacer consultas del tipo "¿Qué cambios en la rama A no se han fusionado en la Rama B?" y cherry-seleccione las soluciones que necesita en la rama de desarrollo.

Answer 2

El artículo aquí (Día a día con Subversion) menciona que un método es actualizar constantemente la versión 2 con datos de la versión 1.1.En el artículo, el chico dice que hagamos esto todos los días.

La parte que querrás leer se titula "¡Camarero, hay un error en mi baúl!".Está aproximadamente a la mitad del artículo.

Answer 3

Probablemente confiaría en un sistema de seguimiento de problemas para este propósito y me aseguraría de etiquetar cada cambio que deba presentarse en el código troncal.Luego puede asegurarse de que los comentarios de registro para cada cambio hagan referencia al problema relevante y sean claros al expresar la intención del cambio de código para que pueda entenderse fácilmente al intentar volver a implementarlo en el tronco.

Answer 4

Más o menos lo que todos los demás han dicho, pero pensé que agregaría mi experiencia en el manejo del desarrollo en múltiples ramas usando SVN.

Con nuestro producto principal, tenemos la necesidad de desarrollar simultáneamente más de 2 versiones al mismo tiempo.

Originalmente utilicé el tronco principal como la versión de "desarrollo principal", con etiquetas utilizadas para cada versión real.Las ramas se utilizaron para importantes esfuerzos de desarrollo de un nuevo conjunto de funciones.Luego, cuando comenzamos a trabajar en 2, 3 y 4 versiones a la vez, comencé a usar una rama para cada revisión.

Dado que mantengo el repositorio y también me encargo de impulsar las compilaciones de control de calidad, me aseguro de hacer "resúmenes" cada mañana, que consisten en fusionar cambios en el árbol comenzando con la rama más baja actualmente activa.Entonces termino fusionando los cambios de 1.1 en 1.2, que se fusiona en 1.3 con cualquier otro cambio de 1.2 desde la última fusión, etc.

Cuando me comprometo, me aseguro de comentar siempre el compromiso con algo como

fusionado 1.1 rev 5656-5690

Puede ser un poco doloroso, pero funciona :)

Answer 5

Fusione temprano, fusione con frecuencia y asegúrese de que el control de calidad en la línea principal conozca y retroceda/verifique los defectos solucionados en cada parche de las versiones de mantenimiento.

Es muy fácil dejar que algo se escape y "corregir" un error en una versión posterior, y déjame decirte que a los clientes no les importa lo complicado que puede llegar a ser administrar múltiples sucursales; ese es tu trabajo.

Asegúrese de estar utilizando un sistema de control de fuente que admita ramificaciones y fusiones (he tenido experiencia con Perforce y SVN, y aunque Perforce es mejor, SVN es gratuito).

También creo que tener una sola persona responsable de realizar las fusiones de manera consistente ayuda a garantizar que se realicen con regularidad.Generalmente he sido yo o una de las personas superiores de nuestro equipo.

Answer 6

La forma en que manejamos esto en mi trabajo es mantener la rama troncal como el código más avanzado (es decir, 2.0 en este caso).Crea una rama para el código 1.x y realiza todas las correcciones allí.Cualquier cambio a 1.x debe fusionarse (manualmente, si es necesario) en la rama troncal (2.0).

Luego insistiría en que los desarrolladores de 1.x tomen nota tanto del número de revisión para la confirmación de 1.x como del número de revisión para la fusión de 2.0 en el ticket de ese error.De esa manera, será más fácil darse cuenta si alguien se olvida de fusionar sus cambios, y el hecho de que tenga que realizar un seguimiento le ayudará a recordar.

Answer 7

Un punto clave se captura en esta imagen de El doctor de la construcción:solo fusiona una dirección.

Answer 8

Para responder a esa pregunta específica, muchos desarrolladores han cambiado de Subversion a Git.Visita github.com.