SubVersion, Eclipse y las ramas de desarrollo. (III) Crear la rama

Vamos a ponernos en situación: tenemos un proyecto y hemos decidido abrir dos vías de desarrollo. Los motivos pueden ser muchos: queremos hacer pruebas de implementación de unas nuevas librerías sin afectar al resto del equipo; queremos continuar con el desarrollo de una fase posterior dejando la rama principal (trunk) al mantenimiento de la fase recién entregada; puede haber mil motivos por los que queramos tener dos caminos paralelos en el desarrollo.

El caso es que, por el motivo que sea, hemos decidido abrir una rama, un branch que diríamos en nuestro querido espanglis. Y nos toca implementar esa decisión en el SVN. Pues nada, ahí vamos. Nos hemos creado 6 ficheros en el proyecto, que resumen los posibles casos que se pueden dar en una situación real:

- Fichero sin modificar en trunk ni en branch
- Fichero modificado en trunk y no en branch
- Fichero modificado en branch y no en trunk
- Fichero modificado en trunk y en branch
- Fichero borrado en trunk
- Fichero borrado en branch


Como es lógico, no va a haber una receta universal para estos archivos. Es decir, en el momento de juntar nuevamente las dos ramas, tendremos que dedicar unos segundos para saber qué tenemos que hacer con cada uno de los posibles conflictos que tengamos, y en ocasiones esto no es fácil. Recordemos que el término conflicto se utiliza (tanto en SVN como en cualquier otro software de control de versiones) para referirnos a un fichero que ha sido modificado simultáneamente por dos personas. Para intentar profundizar en el ejemplo, hemos creado esos seis ficheros por duplicado, una vez en el paquete ganatrunk y otra en el paquete ganabranch. Vamos a ello.

Creación del branch

Desde Eclipse podremos hacer todas las operaciones que vayamos a necesitar, y empezamos con el botón derecho sobre el nombre del proyecto, Team y Branch/Tag. Lo primero es indicar dónde queremos hacer la copia, y eso se lo tendremos que decir a mano. Con el botón Select... nos aparece la pantallita que vemos en la captura, abajo a la izquierda, y ahí escogemos la carpeta branches. Conviene añadir un nivel de subdirectorio más, ya que en branches, posiblemente queramos volver a crear más ramas en el futuro. Así que cuando escojamos la carpeta branches y le demos a aceptar, modificaremos manualmente la URL del campo Copy to URL: y le daremos un nombre de un nuevo directorio dentro de branches: yo le he dado el original nombre de branch01, así que la ruta de mi branch va a ser file:///svn/repo/HelloSVN/branches/branch01. La casilla Create any intermediate folders that are missing (crear todas las carpetas intermedias inexistentes) conviene marcarla también.

La siguiente ventana nos pide el número de revisión desde el que queremos abrir la vía alternativa. Esto depende de la complejidad y del estado del proyecto; para proyectos sencillos como el que nos ocupa, basta con decirle que lo haga desde la HEAD, es decir, desde la última versión del repositorio.

En la última ventana sólo nos pide el comentario para el repositorio: ya sabéis que las buenas prácticas recomiendan añadir siempre un comentario en cada commit que hagamos. Lo importante de esta ventana es la casilla que hay justo debajo del comentario, la que dice Switch working copy to new branch/tag. (conectar la copia local a la nueva rama/etiqueta). Si sois de los programadores que os toca trabajar en el branch recién creado, deberéis marcar esta casilla, si vais a seguir con el desarrollo de la rama principal trunk, no deberéis marcarla. En nuestro caso vamos a mezclar un poco las cosas: vamos a tener en el mismo workspace dos proyectos, uno apuntando al trunk y otro al branch. Este proyecto lo vamos a dejar apuntando al trunk, por lo que no marcamos la casilla. Botón de Finish y... ya tenemos la rama creada.

Visualizamos la rama

Ya tenemos la rama creada, lo que significa que en el repositorio tenemos dos proyectos, que podemos considerar totalmente independientes: el que hay en la carpeta trunk y el que está en branches/branch01. Vamos a abrirnos en el workspace otro proyecto pero apuntando a la rama. Queda claro que en una situación real, no debería haber un ordenador con los dos proyectos abiertos, ya que sería muy fácil editar el archivo del proyecto que no debes editar. Pero aquí lo vamos a hacer así, sólo con el motivo de poder ver el estado de los dos proyectos de un vistazo.

Así que nos vamos a File -> Import -> SVN -> Checkout Projects from SVN, buscamos la carpeta file:///svn/repo/HelloSVN/branches/branch01 y, para evitar confusiones con el proyecto anterior, vamos a llamar a éste HelloSVN_branch. Bueno, ya lo tenemos. Acabamos de abrir la rama, la via de desarrollo alternativa, y como debe ser al principio de la rama, actualmente los dos proyectos no se diferencian en nada. Si os fijáis en la imagen, tienen los dos los mismos archivos, la misma versión de los archivos (la 8), todo igual. En lo único que se diferencian es que uno está conectado a [HelloSVN/trunk] y el otro a [HelloSVN/branches/branch01].

Empezamos a modificar ficheros

Desde este momento, el equipo de programadores de la rama principal hará sus cambios en el proyecto trunk (el de arriba en la imagen) y el equipo de la rama secundaria lo hará en el proyecto branch (el de abajo). Como comentaba al principio del post, vamos a tener 6 tipos de posibles conflictos cuando unamos las dos ramas. Nos faltarían los ficheros que se añaden en una rama o en la otra, pero estos tienen una solución muy simple, por lo que nos olvidamos de ellos. Así que vamos a hacer las modificaciones oportunas en cada uno de ellos, borrando los que tengamos que borrar o modificando arriba o abajo, según sea el caso.

En la primera de las dos imágenes podéis ver los cambios que he hecho en el trunk: he borrado los 2 archivos FicheroParaBorrarEnPrincipal y he modificado FicheroParaModificarEnAmbas y FicheroParaModificarEnPrincipal, en los dos paquetes. Por otro lado he hecho algo parecido en el branch: he borrado FicheroParaBorrarEnRama y he modificado FicheroParaModificarEnAmbas y FicheroParaModificarEnRama, en ambos paquetes también. Y he hecho commit en ambos proyectos, por lo que ambos están sincronizados.

Dejamos para el último post el merge, es decir, la unión de las dos ramas.