Resolución de conflictos

Al actualizar nuestra copia local del repositorio cabe la posibilidad de que existan diferencias incompatibles entre el contenido de algún archivo local y su versión almacenada en el repositorio. Esto es lo que se denomina conflicto. La orden svn muestra los conflictos de la siguiente forma:

   $ svn update
   C   kajongg.po
   Actualizado a la revisión 1116691.

La letra C indica que existe un conflicto (o más) en kajongg.po y que Subversion no sabe cómo resolverlo, por lo que tendremos que resolverlo nosotros de forma manual.

Si miramos el contenido del subdirectorio veremos que existen otros archivos con el mismo nombre y distinta extensión:

   $ ls -1 kajongg*
   kajongg.po
   kajongg.po.mine
   kajongg.po.r1116495
   kajongg.po.r1116691

Cada uno de estos archivos contiene lo siguiente:

• kajongg.po: el archivo original con marcadores de conflictos
• kajongg.po.mine: nuestra copia de trabajo local
• kajongg.po.r1116495: el original con el que hemos trabajado
• kajongg.po.r1116691: la versión más reciente del repositorio

A partir de la versión 1.5 de Subversion se informa inmediatamente al usuario de la existencia de un conflicto, proponiéndole diversas acciones a realizar en ese momento. Las herramientas gráficas para acceder al repositorio se suelen ejecutar en modo no interactivo, por lo que no se le propone al usuario ninguna acción inmediata. En adelante supondremos que no se ha actualizado la copia local del repositorio en modo interactivo.

¿Cómo resolver los conflictos?

Tras actualizar nuestra copia local hemos obtenido un conflicto. Llegados a este punto, disponemos de tres posibilidades para resolverlo:

• Descartar nuestros cambios locales
• Descartar los cambios existentes en el repositorio
• Mezclar ambas versiones en una nueva

Descartar nuestros cambios locales

Esta es la solución más fácil, aunque con ella perderemos el trabajo que hemos realizado en nuestra copia local, por lo que no se recomienda. Para llevarla a cabo desharemos nuestros cambios y luego actualizaremos de nuevo nuestra copia local:

   $ svn revert kajongg.po
   Se revirtió 'kajongg.po'
   $ svn update kajongg.po
   Actualizado a la revisión 1116691.

Descartar los cambios existentes en el repositorio

Esta solución tampoco se recomienda, ya que borraremos los cambios introducidos en la revisión existente en el repositorio (aunque Scripty volverá a introducirlos la próxima vez que se ejecute en el repositorio). De todos modos, para llevarla a cabo tenemos que copiar nuestra versión sobre el original, e indicarle a Subversion que ya hemos resuelto el conflicto:

   $ cp kajongg.po.mine kajongg.po
   $ svn resolved kajongg.po
   Se resolvió el conflicto de 'kajongg.po'

La orden svn resolved borrará todos los archivos especiales que generó la actualización de nuestra copia local.

Mezclar ambas versiones en una nueva

Como traductores, esta es la única forma que se recomienda para resolver los conflictos generados al actualizar nuestra copia local del repositorio.

Si intentamos abrir el archivo kajongg.po en Lokalize obtendremos un mensaje de error. Si queremos ver en qué consisten exactamente los conflictos que se han producido en dicho archivo, tendremos que echar mano de un editor de texto plano, como KWrite (es muy importante que el editor de texto esté configurado para trabajar con la codificación de caracteres UTF-8 y con los finales de línea de UNIX).

El archivo kajongg.po contiene marcas que identifican dónde se ha producido un conflicto. Por ejemplo:

   #: rc.cpp:15 rc.cpp:30
   <<<<<<< .mine
   #| msgid "Definition"
   =======
   >>>>>>> .r1116691
   msgid "Description:"
   msgstr "Descripción"

El principio del conflicto se marca con siete signos < seguidos. Lo que contiene nuestra copia de trabajo local se encuentra entre esta marca (a la que se añade la etiqueta .mine) y la de siete signos =, mientras que lo que contiene la copia del repositorio se encuentra entre estos signos = y la marca de siete signos > (a la que se añade el número de la revisión existente en el repositorio, .r1116691 en este caso).

Como se puede observar en el ejemplo, este conflicto se ha producido porque la revisión con la que hemos estado trabajando localmente contenía un comentario antiguo (#| msgid "Definition") que ha sido eliminado en la revisión 1116691 que contiene el repositorio.

Resolver el conflicto significa decidir cuál de las dos posibilidades es la correcta. Para ello, en el editor de texto borramos las líneas que marcan el principio y el final del conflicto, así como la línea se signos = y el texto de la versión que no queramos que figure finalmente en el archivo.

Procederemos del mismo modo para localizar y solucionar el resto de conflictos que pudieran existir en el archivo antes de guardarlo en nuestra copia local del repositorio.

Finalmente, le indicaremos a Subversion que hemos terminado de resolver el conflicto:

   $ svn resolved kajongg.po
   Se resolvió el conflicto de 'kajongg.po'

Utilidades gráficas

La más conocida puede ser kdiff3, que puede resolver automáticamente la práctica totalidad de los conflictos, informándonos de forma visual de los que necesitan de nuestra intervención. Una de las ventajas de esta herramienta es que nos permite editar el texto directamente en el archivo en el que ser realiza la fusión.

Siguiendo el ejemplo anterior, para resolver el conflicto, ejecutaríamos el programa en el directorio que contiene los archivos problemáticos:

   $ kdiff3 kajongg.po.r1116495 kajongg.po.mine kajongg.po.r1116691 -o kajongg.po

Es importante observar el orden en el que se deben especificar los archivos:

1. el original con el que hemos trabajado (el de la revisión más baja)
2. nuestra copia de trabajo local (el que tiene extensión .mine)
3. la versión más reciente del repositorio (el de la revisión más alta)

Finalmente, usamos el parámetro -o archivo.po para indicar que los cambios se guardarán en dicho archivo.

Tras resolver el conflicto con esta herramienta, le indicaremos a Subversion que hemos terminado:

   $ svn resolved kajongg.po
   Se resolvió el conflicto de 'kajongg.po'

El programa KDEsvn permite lanzar esta herramienta para resolver conflictos de forma automática.

Cómo evitar conflictos

El método de trabajo más recomendable para evitar la aparición de conflictos en nuestra copia local pasa por actualizarla siempre justo antes de ponerse a trabajar en ella y justo después de terminar de trabajar. Tampoco conviene esperar mucho antes de enviar nuestro trabajo al repositorio: es preferible hacer poco trabajo y subirlo cuanto antes, a esperar varias semanas a tener todo traducido para enviarlo.