Crear ramas, etiquetar y realizar merge son conceptos comunes para casi todos los sistemas de control de versiones. En este artículo vamos a adentrarnos en la gestión de ramas dentro de un proyecto de desarrollo con Eclipse. Este proyecto lo tenemos enlazado a Subversion utilizando el plugin Subclipse. Gestionar ramas (branching) es una parte fundamental de un control de versiones, se asume que estás familiarizado con los conceptos básicos de Subversion.

¿Qué es una rama?

Se trata de una línea de desarrollo que existe independientemente de otra. Una rama siempre es una copia de otra y desde el momento de copia contiene su propia historia. Subversion permite mantener ramas paralelas de tus ficheros y directorios. Ayuda a duplicar cambios de una rama a otra y, finalmente, puede hacer que se reflejen cambios de tu copia de trabajo en diferentes ramas por lo que puedes mezclar y enlazar diferentes líneas de desarrollo en tu trabajo diario.

Crear una rama

Vamos con un caso práctico: Lo normal es que el proyecto esté asociado a la línea principal de desarrollo, que llamamos Trunk. Todas las modificaciones y funcionalidades que se deseen incorporar a la versión de producción deberán estar contenidas en esta rama (pueden existir otras estrategias pero ésta es la que usamos en nuestro trabajo). En un momento determinado nos puede interesar abrir otra línea de desarrollo o rama en la que trabajará de forma independiente en el tiempo un desarrollador o equipo de desarrolladores, por ejemplo. Así dejamos la copia de trabajo del Trunk libre por si es necesario una nueva versión de producción de manera inmediata para corregir una incidencia o incorporar una funcionalidad urgente. Para realizar esto hacemos clic sobre el proyecto con el botón derecho del ratón y vamos a Team -> Branch/Tag. Subversion considera exactamente igual una rama (branch) que una etiqueta (tag), es decir, son copias de un conjunto de carpetas y ficheros (se diferencian en que las ramas tienen history y las etiquetas no).

A continuación seleccionamos el directorio en el que se almacenará esta rama. Todas las ramas se suelen guardar bajo el directorio branches del repositorio por convenio. También debemos indicar la revisión sobre la que queremos crear la rama. Si queremos que se haga desde la última versión de desarrollo, seleccionamos la opción HEAD. Por último podemos indicar un comentario, por ejemplo, «Creación nueva rama».
A partir de este momento la copia de trabajo en eclipse pasa a ser la de la rama (si no es así podemos pulsar sobre el proyecto con el botón derecho del ratón y pulsar sobre Team -> Switch to another Branch/tag/revision… para seleccionar la nueva rama), por lo que cualquier modificación que realicemos y subamos al control de versiones se hará sobre ésta. Se harán las modificaciones oportunas en el desarrollo de nuevas funcionalidades y las subiremos al repositorio haciendo commit.

Mantener sincronizada una rama

De forma periódica es conveniente actualizar esta rama con los posibles cambios introducidos en el trunk, ya que aunque no hemos terminado con nuestro trabajo en la rama, deseamos que los cambios en el trunk no se aparten mucho del contenido de la rama, y la sincronización entre ellas sea menos traumática. Ya dijimos que cada rama tiene una línea de desarrollo independiente.

Para realizar un merge del trunk sobre nuestra rama pulsamos sobre el proyecto y vamos a Team -> Merge. Aparecerá a continuación una pantalla en la que debemos seleccionar el modo en el que haremos merge:

Seleccionamos la primera opción «Merge a range of revisions» para incorporar los cambios en el trunk o en otra rama. Deberemos elegir a continuación la localización de los elementos a sincronizar, y como ya habíamos dicho lo vamos a realizar desde el trunk. En la siguiente pantalla podemos especificar las opciones del proceso de merge.

Ya que se han hecho cambios en el trunk mientras nosotros trabajábamos en nuestra rama, pueden aparecer conflictos. La pantalla siguiente nos avisa de que hay un conflicto en una clase que debemos resolver. Para resolverlo elegimos la opción Launch a graphical conflict resolution editor y se abrirá un editor gráfico con ambas versiones y los cambios señalizados de forma gráfica.

Al solucionar manualmente el conflicto y cerrar el editor aparece una pantalla de confirmación de resolución del conflicto. Seleccionamos Yes y pulsamos ok.

Al terminar todo el proceso nos muestra una pantalla de resumen. Ya tenemos en una copia local los cambios del trunk y de la rama. Ahora tenemos que consolidar los cambios a la rama haciendo commit y subiendo las modificaciones al control de versiones (dentro de la rama).

Reintegrar una rama

Qué ocurre cuando has finalizado tu trabajo en la nueva línea de desarrollo. Tu nueva funcionalidad está acabada y está preparada para pasar al trunk, por lo que debemos cambiar la rama asociada al proyecto pulsando sobre el proyecto con el botón derecho del ratón y seleccionar Team -> Switch to another Branch/tag/revision… para asociar al trunk.

A continuación hacemos un merge, como ya indicamos en el punto anterior, ahora con la opción Reintegrate a branch.

En la pantalla siguiente seleccionamos la rama desde la que vamos a sincronizar. El proceso posterior es similar a lo comentado en el punto anterior, sin olvidar que la sincronización se realiza sobre la copia local y que debemos consolidar los cambios haciendo commit.

Evidentemente todo el proceso comentado aquí puede diferir de las necesidades de cada proyecto: puede interesar hacer merge de unos pocos paquetes, algunos módulos, o de ciertas revisions, en vez del HEAD. En el mundo real pueden surgir falsos conflictos en la sincronización, errores de versiones, que aprendemos a manejar con la práctica y experiencia. También tenemos que tener en cuenta que las versiones del cliente subversión y del servidor son compatibles (sobre todo al reintegrar una rama en el trunk puede dar algún tipo de problema). Lo que está claro es que dominar este proceso nos puede facilitar la vida en ciertos proyectos donde concurren desarrollos en paralelo de diferentes módulos.

Versiones

Eclipse Galileo Build id: 20100218-1602

Subversion Client Adapter: 1.6.10

Subclipse Integration: 3.0.0

Eclipse Mylin: 3.3.2