Inicio > Comandos Linux, SVN > Retromerge y svn merge record-only

Retromerge y svn merge record-only

Retomando un poco de SVN, del hace rato no hablaba, les presento un post que tenía en borrador desde hace 6 meses. Para ponermos en contexto, voy a hablar un poco de lo que en mi equipo se llama el retromerge. Supongamos que tenemos la branch (rama) 1.1. Sobre esta branch ya no hay más desarrollos, en consecuencia no deben haber mas commits. A partir de ésta, supongamos que creamos la branch 1.2. Ya hablamos de la creación de una branch en un viejo post. Supongamos además, que sobre esta nueva branch 1.2, ya han habido dos commits. Y que uno de ellos, el n+1, corresponde a un fix urgente de un problema detectado en la 1.2, pero que también está presente en 1.1. La situación se puede resumir en la siguiente imagen:

retromerge01

En este punto alguien podría decirme que n+1 debería haber sido commiteado en la 1.1. Y estoy absolutamente de acuerdo con la apreciación, pero la situación que describo es a propósito. Además, a pesar de todo, sucede muy a menudo en el día a día de los desarrolladores. Para corregir entonces el problema en la 1.1, debemos recuperar el commit n+1 de la 1.2 y mergearlo (razón por la cual llamamos a esto retro-merge). Este merge es casi igual a los merges normales. Primero verfiquemos la lista de commits disponibles para mergear:

joan@jomaora:1.1$ svn mergeinfo http://svn.jomaora.com/proyecto/branches/1.2 --show-revs eligible
r34954
r34955

Supongamos que nuestro n+1 es la revisión 34955 (a mergear y commitear en la rama 1.1). Esta acción crea entonces un nuevo commit (Rev n+2 = 34956) que no está presente en la 1.2.

joan@jomaora:1.1$ svn merge -c 34955 http://svn.jomaora.com/proyecto/branches/1.2

retromerge02

En un mundo perfecto, este nuevo commit debe ser mergeado en la 1.2, para respectar el principio de tener todo commit de la 1.1 en la 1.2. Sin embargo, las modificaciones ya están presentes en la 1.2. Un merge normal del commit n+2 provocaría un conflicto entre los archivos mergeados debido a los cambios textuales (es decir, las líneas modificadas en el archivo). En el retromerge lo que nos interesa no es mergear estos cambios, sino indicar a la 1.2 que integraremos el commit n+2 sin tener en cuenta los cambios textuales. Para esto, utilisamos un parámetro del comande svn merge: –record-only

joan@jomaora:1.2$ svn merge --record-only -c 34956 http://svn.jomaora.com/proyecto/branches/1.1

Para verificar que el merge no ha realizado cambios textuales haciendo un svn st.

joan@jomaora:1.2$ svn st
_M .

En este caso, vemos que la M aparece en la segunda columna, indicando cambios a nivel de las propiedades svn en el directorio.

joan@jomaora:1.2 $ svn commit -m "Merging 34956 (record only from 1.1)"
Sending .

Estas operaciones podemos resumirlas en la siguiente figura:

retromerge03

Los cambios en las propiedades svn los podemos verificar utilizando el parámetro svn:mergeinfo. Con este comando podemos ver los commits que han sido mergeados como record-only.

joan@jomaora:1.2 $ svn propget svn:mergeinfo
/branches/1.1: 34956

  1. Aún no hay comentarios.
  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Hype Driven Development

coz' geeks love new stuff !

My experiments with SCRUM

Site to discuss Agile (Scrum, XP, etc) concepts and ideas.

CommitStrip

Mi propia cheatsheet...

Chris Aniszczyk's (zx) diatribe

work. life. open source. diatribes.

GermanTrevi

repositorio de mi mente...

A %d blogueros les gusta esto: