Inicio > SVN > SVN conflict por supresión entrante

SVN conflict por supresión entrante

Tiempo sin escribir, exceso de trabajo y también mi periodo de vacaciones en Colombia me habían llevado a ocuparme de otras cosas y no de mi blog. Pero ya tenía desde hace rato unos post en borrador. Entre esos, hoy quiero compartir un problemita que tuve que días con un merge.

Todos sabemos que en los grandes proyectos hay muchas personas que trabajan sobre un mismo archivo. También que podemos tener al mismo tiempo versiones paralelas de un software, y personas que trabajan en la versión N y N+1 al mismo tiempo. Para pasar las modificaciones de la versión N a la N+1 se utilisa el comando SVN MERGE.

La situacion que me paso es la siguiente. Supongamos que tenemos un archivo t1.jsp que está en una carpeta t1 de nuestra versión 1.1 (y que estamos en la revisión N). De la versión1.1 se creó la versión 1.2 (generando la versión N+1). Luego sobre la versión 1.1, una persona X hace un refactoring sobre el archivo /t1/t1.jsp, moviendolo a la raíz (un svn copy del archivo, lo que suprime /t1/t1.jsp y agrega /t1.jsp. Revision N+2). Solo que X olvida de hacer su merge y su modificación no impacta la versión 1.2.

Tiempo después, una persona Y que trabaja en la 1.2 hace una modificación sobre /t1/t1.jsp (que todavía existe porque no hubo merge. Revision N+3). Finalmente, a la persona Z, inocente de todo lo que ha ocurrido, le piden en favor de mergear los commits de la 1.1 en la 1.2. La persona Z muy juiciosa, sigue todos los pasos que sugiere mi antiguo post, y voilà con lo que se encuentra:

joan@jomaora:~/test/1.2$ svn merge -c N+2 http://svn.jomaora.com/test/branches/1.1
--- Fusion de rN+2 dans 'proyecto':
A t1.jsp
C t1/t1.jsp
Résumé des conflits :
Arborescences en conflit : 1

Si! Hubiera podido hacer –dry-run antes para darme cuenta que iba a tener un conflicto, pero de todas maneras iba a estar obligado de hacer manipulaciones para resolverlo. El problema es simple y evidente, al hacer el merge, se va a suprimir un archivo que fue alterado ‘después’ de su ‘supresión’.

joan@jomaora:~/test/1.2$ svn st
M .
A + t1.jsp
C t1/t1.jsp
> local édition, suppression entrante sur fusion

No solo el commit N+2 representa un problema, sino que las modificaciones que fueron agregadas en ese archivo, deben ser ahora agregadas en el /t1.jsp, archivo creado de /t1/t1.jsp tras la refacto. Lo que hay que hacer entonces, es hacer la comparación entre la revisión N+1 y N+3 de /t1/t1.jsp sobre la versión 1.2. El comando SVN DIFF nos puede ser de utilidad en este tipo de situacion. Para usarlo necesitamos la url del archivo que queremos analizar, y los numeros de revision entre los cuales queremos hacer la comparación.

joan@jomaora:~/test/1.2$ svn diff -r N+1:N+3 http://svn.jomaora.com/test/branches/12.2/t1/t1.jsp
Index: t1.jsp
===================================================================
--- t1.jsp (révision N+1)
+++ t1.jsp (révision N+3)
@@ -11,6 +11,7 @@
</head>
<body>
-  <h1>Hello World!</h1>
+ <h2>Hello World!</h2>
<hr>
<p>

También se puede utilizar la opción de ver el historial de un archivo en Netbeans para ver las diferencias. Bueno, yo se que el ejemplo del diff es un poco exagerado en cuanto al impacto. (Si, el cambio de un H1 por un H2 a nadie le importa, pero supongamos que son tags tipo <c:foreach> o cualquier otra cosa. En ese caso las consecuencias pueden tener verdaderamente efectos no deseados. En fin, en todo caso, identificadas las líneas que han sido modificadas hay que integrar esa modificaciones a la mano en /t1.jsp. Luego hay que suprimir /t1/t1.jsp.

Ahora solo nos resta indicar a svn que queremos resolver el conflicto. Como hemos suprimido el archivo, vamos a forzar al repositorio a tomar lo que hay en la copia local, es decir, la supresión de /t1/t1.jsp. Para eso, el comando a utilizar es:

joan@jomaora:~/test/1.2$ svn resolve http://svn.jomaora.com/test/branches/12.2/t1/t1.jsp --accept working
Conflicto sur 't1/t1.jsp' resuelto

Finalmente un svn st nos revela el estado de la copia local, sin conflictos, y lista para hacer el comit de merge.

joan@jomaora:~/test/1.2$ svn st
M .
A + t1.jsp

Conclusion: Por favor, hagan sus propios merges y evitenle problemas a los otros desarrolladores. “Clean your own sh**”
Categorías:SVN Etiquetas: , ,
  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: