Creando una nueva rama

Antes de nada hemos de recordar que necesitamos una versión etiquetada, por ejemplo ‘v1_2′, sobre la que vamos a trabajar. Comenzamos extrayendo la versión a nuestro entorno de trabajo:

$ cvs checkout -d proyecto-1.2 -r v1_2 proyecto

Procedamos a crear la rama propiamente dicha:

$ cd proyecto-1.2
$ cvs tag -b v1_2-branch

El nombre de la rama es un gusto personal, yo prefiero añadir -branch aunque he visto -bugfixes o combinaciones de ambos.

Con estos simples pasos ya disponemos de una rama de desarrollo a la que podemos acceder, por ejemplo para hacer un cambio a la rama:

$ pwd
/home/chernando/proyecto
$ cvs up -r v1_2-branch

Si revisamos el estado de ‘main.c’ podemos ver que está incluido en una rama:

$ cvs -q status main.c
==================================================================
Working revision: 1.1.2.1 2007-03-07 19:06:39 +0100
Repository revision: 1.1.2.1 /tmp/repositorio/proyecto/main.c,v
Commit Identifier: QwJwh9fAP56fxb9s
Sticky Tag: v1_2-branch (branch: 1.1.2)
Sticky Date: (none)
Sticky Options: (none)

Importante fijarse en el cambio en la numeración, a partir de ahora en vez de avanzar con 1.X, se avanza con 1.N.X, siendo N la numeración de la rama.

Mezclando dos ramas

Bien, supongamos que queremos traernos cambios realizados desde una rama,’v1_2-branch’, a la principal. Muy fácil, haremos como si forzáramos un cambio de una versión anterior pero especificando la rama en vez de la revisión:

$ cvs update -j v1_2-branch main.c
RCS file: /tmp/repositorio/proyecto/main.c,v
retrieving revision 1.1
retrieving revision 1.1.2.1
Merging differences between 1.1 and 1.1.2.1 into main.c
$ cvs commit -m 'Cambios desde la rama v1.2' main.c

Hay un problema: no podemos hacer esta jugada dos veces seguidas sin dar conflictos

Supongamos que queremos volver a traernos un cambio desde la rama ‘v1_2-branch’ con el comando update. El diferencial de cambios para hacer la mezcla se hace desde la base de la derivación de la rama, si ya hemos aplicado parte de ese diferencial en una actualización anterior provocará irremediablemente un conflicto.

La solución para evitar el engorro de trabajar con conflictos es utilizar una referencia de la rama justo después de traer los cambios. Dos opciones principales:

• Etiquetar la rama cada vez que se traen cambios de ellas, ‘v1_2- branch-fixes-1′.
• Utilizar las nociones de tiempo de CVS, ‘v1_2-branch:3 days ago’.

La idea intuitiva es la de señalar en el historial de la rama dos marcas de tiempo, la última que se llevo a la principal y el actual de la rama, y aplicar los cambios que se realizaron entre esos dos instantes en la rama en la principal. Por ejemplo:

$ cvs update -j v1_2-branch-fixes-1 -j v1_2branch

svk está basado en el sistema de ficheros de subversion, está escrito en Perl y cuenta con varias mejoras que le permiten ser un decentralized version control system. Su principal objetivo es permitir a un desarrollador disponer de sus propias ramas privadas facilitando enormemente el proceso de merge.

La situación es la siguiente: disponemos de un repositorio central con un proyecto en el que estamos trabajando. Mediante svk vamos a hacer una copia del repositorio, vamos a mantenerlo actualizado y vamos a crear nuestra propia rama de trabajo.

Preparando nuestro entorno

En primer lugar crearemos un repositorio en el que vamos a guardar la copia del repositorio central:

svk depotmap --init

Este comando creará en ~/.svk/local un repositorio típico de subversion al que podremos acceder cómodamente mediante la ruta //.

Disponemos de // para guardar los proyectos que necesitemos, en este caso realizaremos una copia local de un proyecto externo.

svk mirror https://acm.asoc.fi.upm.es/svn/jurix/jailexec/trunk //jailexec

y para actualizar su contenido:

svk sync //jailexec

Durante el proceso de este comando veremos como svk descarga todo los commits realizados en el repositorio central y los replica en nuestro repositorio local, de esta forma conseguiremos disponer de una copia local de todo el repositorio (incluido historial y diferencias).

Importante: resaltar que utilizamos la ruta //jailexec para especificar el lugar en el que hacemos la copia.

Bien, ya tenemos todo lo necesario. Podemos desconectarnos de la red hasta que necesitemos o bien subir nuevos cambios o bien actualizarnos con los cambios del repositorio central.

El trabajo del día a día

Ahora crearemos nuestra copia local de trabajo, al igual que hacíamos con svn o cvs:

svk checkout //jailexec

Esto creará un directorio jailexec en el que tendremos una copia local de trabajo. Un detalle curioso es que no existen directorios especiales .svk ya que las copias de trabajo se gestionan internamente. Hay que tenerlo en cuenta a la hora de eliminar una copia de trabajo, un simple rm -rf proyecto no es recomendable.

A partir de aquí el ciclo de trabajo es el mismo. La única diferencia es que estamos trabajando contra un repositorio local –nuestra copia del repositorio central– por lo que algunos comandos tendrán comportamientos distintos.

• commit: si realizamos un commit contra nuestro repositorio svk forzará automáticamente el envio contra el repositorio central, es transparente al usuario.
• update: actualizaremos respecto a nuestro repositorio, por lo que si no realizamos un sync previo (apartado anterior) no tiene mucho sentido.

Manejo de ramas

Hasta el momento disponemos de una copia del repositorio central, vamos a trabajar con las ramas privadas:

svk cp -p //jailexec //local/jailexec

La opción -p es para crear //local.

Hemos creado //local/jailexec como una rama solamente disponible en nuestro repositorio local, nuestra rama privada.

svk checkout //local/jailexec
o
svk switch //local/jailexec

Nos prepara el entorno de trabajo sobre nuestra rama privada. A partir de ahora los cambios y el historial permaneceran en nuestro repositorio, sin conocimiento alguno del repositorio central.

Supongamos que hemos estado trabajando sobre una rama privada y queremos subir los cambios al repositorio central. Aquí svk nos facilita las cosas:

svk smerge //local/jailexec //jailexec

Este comando juntará ambas ramas de forma automática. No olvidemos que //jailexec es una copia del repositorio central por lo que al juntar ambas ramas se forzará el envio al repositorio central.

Con un solo comando podemos enviar todos los cambios que hemos realizado en nuestra rama privada

La única pega resulta ser la actualización de nuestra rama privada respecto a las actualizaciones del repositorio central:

svk sync //jailexec
svk smerge //jailexec //local/jailexec
svk up (en el directorio de nuestra copia local)

Actualizamos nuestro repositorio local y luego juntamos los cambios en nuestra rama local. Por último actualizamos nuestra copia local de trabajo.

Resumen

svk nos ofrece una estructura estupenda sobre la que trabajar y/o hacer copias de repositorios (oficialmente soporta Subversion, CVS y Perforcer) con una sintaxis idéntica a la de subversion.

El inconveniente es que el manejo resulta un poco complicado durante los primeros días.

A primera vista los dvcs son simples vcs sin un repositorio centralizado, es decir, disponemos de varios repositorios funcionalmente idénticos pero que pueden seguir líneas de desarrollo propio para más tarde sincronizarse entre ellos. A decir verdad parece una forma rebuscada de hacer copias de seguridad de un repositorio clásico.

Supongamos que estamos trabajando en un proyecto cualquiera cuya política a la hora de aceptar un commit es “no introducir código inestable”. Si queremos implementar un gran cambio tendríamos que desarrollar sin ningún vcs hasta conseguir un código maduro y poder realizar el commit, normalmente no suele ser una situación agradable.

La solución más común es la de crear una rama en la que podamos desarrollar tranquilamente y más tarde, una vez madurado el código, juntar nuestra rama con la línea principal de desarrollo. El inconveniente ahora es la gestión de las ramas –crear y destruir múltiples ramas– y hacer el merge que siempre han resultado ser operaciones complicadas e incómodas.

Este es uno de los motivos por los que Linus Torvalds no migró a subversion después de los problemas con BitKeeper: Please Stop Bugging Linus Torvalds About Subversion.

Los dvcs se centran en este problema. Ofrecen al programador mayor libertad a la hora de compartir su trabajo (ya sea con ramas privadas o controlando los cambios a commitear) sin perder en ningún momento un vcs en el que apoyar su desarrollo. Además disponemos de una copia local del repositorio maestro lo que nos permite trabajar (commit, log, diff…) sin disponer de una conexión permanente.

Algunos ejemplos:

• svk trabaja sobre subversion.
• darcs hecho en Haskell y basado en La teoría de los parches, muy curioso.
• GIT la respuesta de Torvalds.
• monotone.
• …