He hablado en varias ocasiones en el blog sobre subversion, un sistema de control de versiones que he utilizado para llevar el control del código fuente de algunos programas. Una entrada que tenía pendiente desde casi hace un año es el uso de ramas (branches)
Ramas
Las ramas es una herramienta que nos permite seguir vías alternativas de desarrollo para poder posteriormente, si se desea, juntar los cambios en un camino principal. Supongamos que tenemos una serie de ficheros en los que estamos desarrollando que se llama trunk. Llegado el momento, queremos probar una serie de mejoras, una nueva funcionalidad, y no queremos que este código principal de desarrollo se toque, entonces lo que se crea es una nueva_rama, que no deja de ser una copia del código en un momento determinado del tiempo, donde el desarrollo diverge:
Cuando estamos en la situación del gráfico anterior hemos realizando una operación de crear una nueva rama en el punto uno. Podremos desarrollar en cualquiera de las ramas, (trunk o nueva_rama), y llegado el momento, lo normal es que integremos los cambios que nos interesen dentro de la rama trunk. ¿Por qué esta rama?. Porque por convenio, en subversion, la rama principal de desarrollo se llama así.
Normalmente la estructura de directorios un proyecto de subversion es tal como sigue:
proyecto
trunk
branches
tags
Nosotros trabajamos dentro del directorio trunk que se corresponde con la rama principal de desarrollo. Ahora, ¿Cómo se crea una nueva rama a partir de una rama existente o la principal?. Pues se usa una copia de la rama que deseemos, usando el comando svn copy. Así por ejemplo, para copiar desde la rama trunk a nueva_rama tal como se ve en el caso anterior. En este caso estamos dentro de un repositorio de un proyecto llamado proyecto_svn
swordcoast:proyecto_svn terron$ svn copy trunk branches/nueva_rama
A branches/nueva_rama
swordcoast:proyecto_svn terron$ svn status
A + branches/nueva_rama
swordcoast:proyecto_svn terron$ svn commit
swordcoast:proyecto_svn terron$cd branches/nueva_rama
Tras ejecutar la última orden, estaremos dentro del directorio de nueva rama, podremos seguir editando y modificando la misma, sin tocar la rama trunk, o bien mientras otros desarrolladores tocan dicha rama. Un detalle interesante respecto al concepto de rama dentro de subversion, es que realmente no hay ninguna "rama" real ni ninguna estructura interna que haga referencia a la misma, sino que no deja de ser una copia de un directorio determinado.
La última operación que nos queda cuando usamos ramas es mezclar (merge) los cambios de dos ramas. ¿Cómo realizamos dicha operacion?.A través del comando svn merge. Lo primero que debemos saber es la revisión que tiene cada rama que deseemos mezclar. Si seguimos con nuestro ejemplo, supongamos que la rama trunk está en la revisión 100 y la rama nueva_rama está en la revisión 150. Queremos incorporar a la rama trunk todos los cambios que hemos realizado en la rama nueva_rama. Para ello, dentro de nuestro directorio de proyecto:
cd trunk
svn merge -r 150:100 ../branches/nueva_rama
svn commit
Si todo va bien, la secuencias de comandos anteriores incorporará a la rama trunk los cambio que hemos desarrollado en la rama nueva_rama. A partir de aquí podemos dar por finalizado el trabajo en dicha rama, o bien seguir trabajando en las dos - esto es útil cuando se quiere tener una rama de desarrollo y otra estable, por poner un ejemplo sencillo -.
Sin embargo, puede producirse conflictos entre las versiones que la lógica automática del subversion sea incapaz de corregir. Llegado el momento, el sistema nos preguntará que queremos hacer:
Select: (p) postpone, (df) diff-full, (e) edit, (r) resolved,Lo que nos está pidiendo el sistema es una serie de opciones para ver que hacemos con aquellos merge que hayan fallado:
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options:
- p Dejar los cambios para más tarde.
- df Nos muestra un diff completo de todos los ficheros que han cambiado.
- e Editamos el fichero que ha fallado al hacer el merge, para editarlo manualmente.
- r Damos el merge por resuelto.
Lo normal en caso de que haya ocurrido un error en esta fase, es editarlo, resolviendo los posibles conflictos y luego hacer el commit. El tema de conflictos entre ficheros, lo trataré en un artículo posterior, de momento dejo aquí estas pequeñas pinceladas de como resolverlo.
Referencia
Technorati Tags: svn
No hay comentarios:
Publicar un comentario