Fusionar cambios suena bastante simple, pero en la práctica puede convertirse en un dolor de cabeza. El problema es que si fusiona cambios con frecuencia de una rama a otra, puede acabar fusionando accidentalmente el mismo cambio dos veces. Cuando esto ocurre, a veces las cosas seguirán funcionando bien. Cuando aplica un parche a un fichero, Subversion normalmente se da cuenta de que el fichero ya contiene el cambio, y no hace nada. Pero si el cambio ya existente fue modificado de algún modo, obtendrá un conflicto.

Idealmente, su sistema de control de versiones debería prevenir la doble aplicación de cambios a una rama. Debería recordar automáticamente qué cambios fueron recibidos en la rama, y ser capaz de mostrarle un listado de los mismos. Debería poder usar esta información para automatizar las fusiones tanto como sea posible.

Desafortunadamente, Subversion no es tal sistema. Al igual que CVS, Subversion 1.0 no almacena ninguna información sobre operaciones de fusionado. Cuando envía sus cambios locales, el repositorio no tiene idea si esos cambios vinieron de una ejecución del comando svn merge, o de una modificación manual de los ficheros.

¿Qué significa esto para usted, el usuario? Significa que hasta que llegue el día que Subversion desarrolle esta característica, tendrá que gestionar usted mismo la información de fusionado. El mejor lugar para hacerlo es en el informe de cambios cuando envía cambios al repositorio. Tal y como se demostró en el ejemplo anterior, es recomendable que su informe de cambios mencione el número de revisión específico (o rango de revisiones) que está siendo fusionado en su rama. Más tarde, puede ejecutar svn log para revisar qué cambios contiene ya su rama. Esto le permitirá construir con cuidado siguientes comandos svn merge que no serán redundantes con cambios previamente portados.

En la siguiente sección, le mostraremos algunos ejemplos de esta técnica en acción.

Dado que el fusionado sólo genera modificaciones locales, normalmente no es una operación de alto riesgo. Si se equivoca en el fusionado la primera vez, simplemente ejecute svn revert para ignorar los cambios y pruebe de nuevo.

Es posible, no obstante, que su copia local ya tenga algunas modificaciones. Los cambios aplicados por una fusión se mezclarán con sus modificaciones locales, por lo que ejecutar svn revert ya no es una opción. Los dos conjuntos de cambios quizás sean imposibles de separar.

En casos como este, la gente se reconforta con la idea de ser capaces de predecir o examinar las fusiones antes de que ocurran. Una manera simple de hacerlo es ejecutar svn diff con los mismos argumentos que planea pasar a svn merge, tal y como ya le enseñamos en el primer ejemplo de fusionado. Otro método de visualización previa es pasar la opción --dry-run al comando de fusionado:

$ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
#  nothing printed, working copy is still unchanged.

La opción --dry-run en realidad no aplica ningún cambio a su copia local. Únicamente muestra los códigos de estado que serían mostrados durante una fusión de verdad. Esto es útil para obtener una visualización previa de “alto nivel” de la potencial fusión, para aquellos casos en los que ejecutar svn diff proporcionaría demasiados detalles.

Cuando hable con un desarrollador de Subversion, es muy posible que oiga alguna referencia al término ascendencia. Esta palabra es usada para describir la relación entre dos objetos en un repositorio: si ambos están relacionados, entonces se dice que un objeto es el ancestro del otro.

Por ejemplo, suponga que envía cambios al repositorio en la revisión 100, los cuales incluyen un cambio al fichero foo.c. Entonces foo.c@99 es un “ancestro” de foo.c@100. Por otro lado, suponga que hace efectivo el borrado de foo.c en la revisión 101, y entonces añade un nuevo fichero con el mismo nombre en la revisión 102. En este caso, foo.c@99 y foo.c@102 pueden parecer relacionados (tienen la misma ruta), pero de hecho son objetos completamente diferentes en el repositorio. No comparten historial o “ascendencia”.

La razón de mencionar esto ahora es para señalar una diferencia importante entre svn diff y svn merge. El primer comando ignora la ascendencia, mientras que el segundo es muy sensitivo a ella. Por ejemplo, si usase svn diff para comparar las revisiones 99 y 102 de foo.c, vería ficheros diferenciales basados en líneas; el comando diff esta comparando a ciegas ambas rutas. Pero si usase svn merge para comparar ambos objetos, se daría cuenta de que no están relacionados y primero intentaría borrar el fichero antiguo, y entonces añadir el nuevo; vería D foo.c seguido por A foo.c.

En la mayoría de las fusiones se comparan árboles que están relacionados por ascendencia, y por esta razón svn merge sigue este comportamiento por defecto. No obstante, ocasionalmente puede querer que el comando de fusionado compare dos árboles no relacionados. Por ejemplo, puede haber importado dos árboles de código fuente representando diferentes versiones de un proyecto de software (lea “Ramas de proveedores”). ¡Si usase svn merge para comparar los dos árboles, vería que el primero es borrado completamente, seguido de una adición completa del segundo!

En estas situaciones, querrá que svn merge realice una comparación basada únicamente en rutas de fichero, ignorando cualquier relación existente entre ficheros y directorios. Añada la opción --ignore-ancestry a su comando de fusionado, y se comportará del mismo modo que svn diff. (Y de modo similar, la opción --notice-ancestry hará que svn diff se comporte como un comando de fusionado.)