Subversion Merge: ¿Cómo reintegraré limpiamente una rama 'Definitiva'?

Question

Hemos estado experimentando con una nueva técnica para administrar nuestras sucursales de lanzamiento.

En general, mantenemos nuestro lanzamiento actual en el tronco y creamos ramas de lanzamiento para cada lanzamiento. La rama de publicación es donde generalmente se produce el desarrollo activo, y el enlace troncal se utiliza para corregir errores en la versión actual.

Hemos estado fusionando periódicamente las correcciones de errores del tronco en la rama de lanzamiento (semanalmente).

Ahora que estamos listos para otra versión, nos gustaría fusionar la rama de lanzamiento en la cajuela. Desafortunadamente, esto lleva a muchos conflictos (> 50). Al principio me sorprendió, pero ahora entiendo que Subversion no puede rectificar fácilmente los cambios en la rama con lo que existe en el tronco.

¿Hay alguna manera de decirle a Subversion que use todas las versiones de los archivos en la rama cuando integre de nuevo en el maletero? Sabemos que las versiones de rama de los archivos son 'correctas'.

Como alternativa, podríamos abandonar teóricamente el tronco y simplemente trabajar fuera de la (s) rama (s) - ramificando desde la rama para las versiones.

Utilizamos TortoiseSVN y Subclipse.

Answer 1

Desde la salida de svn help merge:

--AcepteARG

especificar la resolución de acciones conflicto automática ('posponer', 'base', 'mío-conflicto', ' ellos-conflicto', 'mío-completo', 'ellos-completo', 'editar', 'lanzamiento')

T o acepte los cambios de la bifurcación al fusionarse con la troncal, necesita la opción "--accept theirs-full".

No creo que TortoiseSVN 1.6.2 tenga una opción equivalente en la GUI. Todavía puede interactively resolve conflicts seleccionando "use repository" ya que cada conflicto se encuentra durante la fusión.

Answer 2

Tal vez me está faltando algo aquí, pero parece que la opción más fácil sería eliminar el tronco y volver a crearlo mediante la bifurcación de su nueva rama de lanzamiento.

Answer 3

En teoría, podría hacer una "fusión de dos árboles diferentes" desde la cabeza del tronco hasta la cabeza de la rama. Este debe evitar cualquier conflicto extraño debido a la reintegración.

Answer 4

Creo que lo que estaba haciendo copiando correcciones de errores del tronco a su rama de lanzamiento a veces se conoce como rebasing. Todos los medios de rebase en este caso es que tome una rama que normalmente se basa en la revisión r49 del tronco y fusione los cambios de, por ejemplo, r50-r57 del tronco en la rama, de manera que ahora puede considerar esa rama como basada en la revisión r57 del tronco en lugar de la revisión r49.

El problema en la práctica es que al fusionar un rango de revisiones desde el tronco o cualquier otra base en una de sus ramas no reinicia la revisión base en la que se creó esa rama sino que deja las propiedades normales mergeinfo como la única forma de saber qué se ha fusionado. Para poder reintegrar los cambios de una rama a su base (como el tronco) sin repetir involuntariamente los cambios de la base fusionada, digamos que desde r50-r57 en mi ejemplo anterior se fusionarán los cambios de la rama a la base por cherry seleccionando revisiones particulares de manera que las revisiones causadas por el rebase (fusión de la base a la rama) no están incluidas.

Desafortunadamente, los desarrolladores de Subversion tendrían que implementar una forma de automatizar esto para que solo las revisiones que no contengan una propiedad mergeinfo describan una combinación que contenga solo revisiones entre la revisión base original y el objetivo revisión de la base (generalmente HEAD). Esto se vuelve más complicado ya que a menudo las fusiones incluyen cambios manuales que se comprometen junto con la fusión de una rama que se perdería y también el origen de cualquier objeto dado tendría que ser rastreado hasta su antecesor común para que esto funcione correctamente en staircased ramas. Aparte de eso, una característica que permitiría que una sucursal sea reemplazada por una copia más nueva de la base o el tronco con todas las confirmaciones anteriores reaplicadas como una serie de compromisos separados también lo haría posible y sin embargo incómodo se comportaría más como una verdadera rebase .

Estos comentarios no son una respuesta definitiva, pero representan mi comprensión como un usuario de Subversion desde hace mucho tiempo. Si alguien tiene otros puntos para agregar o puede elegir algo que puede ser incorrecto en mis declaraciones, hágamelo saber por todos los medios para que podamos obtener una comprensión real de las capacidades y limitaciones de la implementación actual de Subversion.

Actualización: De acuerdo con la documentación de Subversion parece que cuando se utiliza el --reintegrate option que Subversion debería poder reintegrarse adecuadamente el trabajo realizado en una rama de un modo que la mente las posibles fusiones de refresco que puede haber sido hecho para traer de base cambios en la rama. Por supuesto, esto es técnicamente un poco diferente al rebasado, pero creo que es lo suficientemente similar en el uso que podría denominarse como rebase. La pregunta principal ahora es si - la opción de integración funciona cuando los cambios desde la base se han fusionado en el tronco de una manera seleccionada en lugar de fusionar todo, desde BASE + NEXT hasta HEAD.

Actualización: Parece quecherry picking should be supported así cuando se utiliza el SVN se funden --reintegrate opción para Subversion 1.5 o superior. Seguir estas instrucciones debería permitirle reintegrarse sin causar conflictos no intencionados debido a revisiones de cambio de rebase de reintroducción.

Para obtener más información, lea el libro de Subversion en la sección titulada Keeping a Branch in Sync.