Mercurial: Cambios específicos de la rama siguen volviendo después de la fusión ficticia

Question

Tengo un repositorio mercurial con dos ramas permanentes, por defecto y UAT. De vez en cuando, implementamos (promovemos) una nueva versión de nuestra aplicación en el entorno UAT y lo hacemos fusionando una confirmación estable predeterminada en la rama UAT. Ocasionalmente, las cosas se corregirán con errores en la rama UAT, y estas correcciones de errores se fusionarán nuevamente a sus valores predeterminados.

En la rama UAT tengo que cambiar algunas cosas para fines de implementación: cadenas de conexión y varias configuraciones ambientales. Lo que intenté hacer fue hacer estos cambios en la rama UAT y enviarlos (todo como uno) justo después de haber combinado el valor predeterminado en UAT. A continuación, simulé la confluencia de este compromiso con el valor predeterminado: la creencia es que, como el valor predeterminado ahora tiene este compromiso en su ascendencia, las correcciones futuras de errores de UAT a valores predeterminados no intentarán rehacer estos cambios específicos de UAT.

Sin embargo, las cosas no han ido tan bien como esperaba. Comenzando con el muñeco-fusionado a cometer por defecto, he intentado tanto de los siguientes escenarios:

1) Make a few more commits to default and then "promote" to UAT (merge default onto UAT) 
2) Make a bugfix on UAT and "backport" it to default (merge UAT onto default) 

En entre correr # 1 y # 2 Me he despojado de todo de manera que ambos escenarios parten del mismo punto .

Lo que estoy viendo es que dependiendo de la última dirección fusionada, todavía tengo que inspeccionar los archivos cambiados después de hacer una u otra combinación y revertir - a veces la fusión intenta poner las configuraciones predeterminadas en UAT y, a veces, el UAT configuraciones en fusión

Si restituyo los cambios de configuración y confirmo la fusión, las fusiones futuras en la misma dirección se comportarán correctamente, pero en el momento en que voy en la otra dirección, la fusión vuelve a poner las configuraciones incorrectas en los archivos.

¿Qué me estoy perdiendo?

Answer 1

Creo que el problema es similar al problema en this question: la fusión no funciona de la manera que usted cree que funciona. La fusión es solo una cuestión de comparar estados de archivo, es no una cuestión de aplicar cambios de una rama a otra.

Su punto de partida es una historia como esta:

UAT:  ... x --- y --- z 
          \ 
default: ..... a --- b --- c 

donde x y y contienen los ajustes de configuración para la UAT y b es la fusión ficticia sin ajustes de configuración. Entonces los archivos en b se ven como en a - se fusionaron.

Si ahora haces un nuevo cambio en default que desea promover a la UAT, que vamos a trabajar con:

UAT:  ... x --- y 
        \ 
default: ..... a --- b --- c 

La fusión está entre y y c. Es una fusión degenerada donde el ancestro común es y. Esto significa que todos los cambios entre b y c "ganarán" en la combinación de tres vías. La tabla de la forma en trozos se fusionan en una combinación de tres vías es:

ancestor local other -> merge 
old  old old  old (nobody changed the hunk) 
old  old new  new (they changed the hunk) 
old  new old  new (you changed the hunk) 
old  new new  new (hunk was cherry picked onto both branches) 
old  foo bar  <!> (conflict, both changed hunk but differently) 

Tenga en cuenta que el resultado de la fusión no depende de la "dirección" de la fusión: la tabla es simétrica con respecto a la local y other columnas.Aquí, tanto ancestor como local es y, y other es c. Por lo que la mesa se convierte en:

ancestor local other -> merge 
old  old new  new (they changed the hunk) 

Se puede ver que el resultado de la fusión siempre contiene el cambio new que se hizo en c.

No es importante que la fusión haya sido degenerada. Suponiendo que tiene una nueva confirmación en UAT y que esta confirmación no toca las cadenas de configuración, obtendrá el mismo comportamiento cuando se fusione (en cualquier dirección, las fusiones son simétricas).

La solución normal a este problema es externalizar las cadenas de configuración. Colóquelos fuera del control de la versión: variables de entorno, un archivo de configuración no versionada, etc. Si puede, coloque un archivo de configuración bajo control de versión como plantilla . A continuación, crea un archivo de configuración no versionado para la rama UAT que incluye el archivo de configuración controlado por la versión. Usted anula la configuración según sea necesario en este archivo de configuración sin versión.