Subversion: La fusión de subárboles frente de fusiones,

Question

adelantarse deSubversion feature branch requires changes from another feature branch

Tengo dos ramas de características: "FeatureA" y "FeatureB". FeatureA está completo, pero no se fusionó con trunk porque no se ha confirmado si debería ir en la próxima versión o no.

FeatureB está en progreso, y resulta que se requieren algunos cambios en dbml que se han aplicado realmente a Feature A.

Tengo algunas opciones, una de las cuales es fusionar solo el dbml y los archivos asociados. Soy consciente de que es una buena práctica fusionar/actualizar/comprometer etc. de la raíz de copia de trabajo, pero ¿qué problemas podría causar si tuviera que seguir adelante?

Answer 1

Al final resolví este problema acordando con mis gerentes que si tengo este problema, que simplemente construiré las dos características en una sola rama y tendrán que unirse y probarse juntas.

Answer 2

Puede fusionar todas las revisiones desde FeatureB a FeatureA branch que desee (es una buena idea observar las revisiones fusionadas, ya que la subversión no lo haría por usted, la herramienta svnmerge.py hace eso, pero prefiero mantener una grabar yo mismo). A continuación, deshaga/elimine los cambios que no desee (como, como ha comentado en la pregunta anterior, son parte de las revisiones).

Quería decir esto: "Más adelante, durante la fusión de FeatureA y FeatureB con trunk, no debería haber conflictos si los cambios que deshace eran independientes de los otros cambios en la rama FeatureB." Pero no estoy seguro de si esto es cierto. Es decir, ¿hay un conflicto/doble cambio si hay un cambio común en FeatureA y FeatureB, cuando estos cambios se fusionan en trunk?

Una solución alternativa es adoptar un enfoque seguro y hacer la contabilidad difícil usted mismo, de modo que cualquier cambio no se repita en absoluto cuando se realiza una fusión posterior en el enlace troncal.

Una forma de simplificar es utilizar un indicador en el código para activar o desactivar FeatureA. De esa forma, FeatureA ya puede fusionarse con trunk.

Answer 3

Desde la versión 1.6 Subversion traza una fusión, por lo que no tendrá más problemas.

Answer 4

Me resulta útil recordar que las fusiones en svn se describen con tres parámetros. Usted toma los cambios que convierten rev X en Rev Y, y aplica esos cambios a rev Z. Creo que esto entra en conflicto con lo que dijo sobre el uso de la copia de trabajo.

De modo que un enfoque sería encontrar los cambios que realizó en el dbml en la rama Feature A (identificada por una revisión de inicio y una de finalización), y aplicar esos cambios a la rama Feature B.

Answer 5

Creo que se trata de la cuestión de "subárbol mergeinfo". Los expertos say this is best avoided. Pero el rendimiento también es un problema, ya que ejecutar una fusión en la raíz de una rama grande puede llevar mucho tiempo. Para evitar esos problemas de rendimiento, he realizado fusiones de subárboles y puedo confirmar que el subárbol resultante mergeinfo causa algunos problemas. Entonces debes evitarlo cuando sea posible.