Consejos para la fusión manual de código divergente

Question

Estoy bastante acostumbrado a usar svn para la bifurcación y la fusión, normalmente esto funciona bien. Sin embargo, se trabajó en un componente en dos ramas y, básicamente, tomó el componente en diferentes direcciones, por lo que la fusión automática no funcionará y usar más allá de comparar muestra que los archivos son en su mayoría diferentes.

He intentado unir algunos de los archivos, pero los resultados, incluso si funcionan, son bastante horribles.

Estoy tentado de decirle al negocio que esto simplemente no se puede hacer. Puedo ver esto frustrando a ellos ya que tienen módulo + función A funcionando y módulo + función B funcionando pero módulo + función A + función B simplemente no tiene sentido tal como está. Por ejemplo, la característica A puede eliminar algo que fue un componente clave en la característica B.

¿Hay alguna manera de intentar fusionar dicho código? ¿O es el módulo + A + B realmente el módulo + C?

Lo vimos venir, pero la función A era necesaria en una escala de tiempo más corta que la característica B, que era parte de un proyecto de larga ejecución. ¿Hay formas de trabajar para evitar que esto suceda? ¿O son sus formas de estructurar el código para que ambas características encajen perfectamente?

Answer 1

Lo que estás diciendo es esencialmente tratar de volver a establecer una base de una de las ramas. Hay soporte para esto en some DVCSs pero no conozco ningún soporte para este tipo de cosas en SVN.

Su mejor opción es elegir una de las ramas (la que es más importante tener ahora) y unirla a la línea principal, que debería ser bastante directa. En la otra rama necesitarás sacar los cambios del maletero y reconciliar las diferencias, dada la situación que describes, esto seguramente no será automático y es posible que tengas que pasar un tiempo muy serio pensando en cómo implementar las características de estas ramas en la parte superior. del que se fusionó con la línea principal, pero ese es el costo del desarrollo paralelo: las cosas cambian.

¿Cómo se puede evitar esto en el futuro? Frequent integration.

Si tiene dos equipos que tienen cada uno una base de datos A y van a trabajar en funciones diferentes durante 6 meses, la integración será muy dolorosa ya que cada uno hará suposiciones acerca de A que el otro equipo ha cambiado. Por otro lado, con las compilaciones de integración semanal o mensual, cada equipo debería estar sustancialmente más al tanto de los cambios que está haciendo el otro y la integración final debería ser mucho más fácil.

Esta es la razón por la que los proyectos de código abierto a menudo se oponen a enormes parches, se vuelven sorprendentemente rápidos y nadie tiene tiempo para revisarlos adecuadamente. Por otro lado, si toma la misma contribución y la descompone en varias partes pequeñas digeribles que son independientes, es mucho más probable que su contribución sea A) aceptada y B) revisada adecuadamente para que no dé como resultado un flujo interminable de defectos.

Answer 2

Tome un solo archivo, diga src1.c. Puede construir un diagrama de diamante que describe la combinación de esta manera:

Original src1.c 
     /  \ 
    /  \ 
    /   \ 
    b1 src1.c  b2 src1.c 
     \   /
     \  /
     \  /
     \ /
     merged src1.c 

Dónde b1 significa la primera versión rama y b2 significa la segunda versión rama. Puede comparar diferencias paralelas (digamos la que existe entre la fuente combinada y la versión b2, y b1 y la original). Esto puede ayudar.