Bazaar: Sistema de control de versiones
En la caja de herramientas de un desarrollador siempre podemos encontrar un sistema de control de versiones preferido. Mi experiencia personal me llevó primero a cvs y subVersion, el cual estoy utilizando actualmente. Este domingo de investigación me lleva a leer algo sobre Bazaar Version Control System, un sitema de control de versiones que promete ser “Version Control for Human Beings“. Veamos como es la experiencia de usuario.
Funcionamiento Básico
Lo primero que hago es ir al tutorial titulado “Bazaar in five minutes” que suena muy prometedor.
la parte de instalacion dice que probablemente el programa ya está en mi distribución y que la instalación deberia ser facil. Estoy algo malcriado por debian y normalmente asumo esas dos cosas, veamos.
# aptitude install bazaar
Presto! Bazaar instalado. Tambien hay instrucciones para MacOS X y ese otro sistema que mucha gente usa.
Luego bazaar nos pide que nos presentemos!
# bzr whoami "Lucas Caro <lucas@triplesmart.com>"
Una vez presentados, chequeamos por las dudas
# bzr whoamiLucas Caro <lucas@triplesmart.com>
Parece que esta todo bien, creemos un proyecto entonces
# mkdir -p myproject/subdirectory && cd myproject && touch test{1,2,3}.txt subdirectory/test4.txt
e inicializamos bazaar:
# bzr init
Esto nos crea un directorio .bzr con muchos archivos dentro que guardan la informacion de bazaar. Paso siguiente, agregamos todos los arvhivos a bazaar con
#bzr add
Que sin argumentos agrega todo recursivamente (muy conveniente) al repositorio. Lo unico que falta es hacer commit del repositorio, pero, ¿Dónde está guardando bazaar el repositorio, las versiones, etc? Parece que en el .bzr tenemos un directorio branch que es donde se guarda todo, y al hacer commit estamos guardando un snapshot del código (o version) tal y como está ahora. Parecido a lo tradicional, pero con Bazaar el proyecto se guarda dentro del arbol de directorios.
# bzr commit -m "Initial Import"
Guarda los cambios con el respectivo mensaje. Hasta ahora, parece ser un sistema de control de versiones que no necesita que un administrador cree un repositorio, administre usuarios, etc. veremos como se las arregla.
Cuando queremos hacer un cambio o editamos un archivo, tenemos a nuestra disposición un comando para ver las diferencias entre nuestra copia de trabajo y el repositorio
# bzr diff
nos dice estas diferencias. y siempre podemos hacer commit para unificar nuestros cambios con el repositorio.
Flujos de Trabajo
Por lo que vimos hasta ahora, bazaar sirve muy bien al desarrollador solitario, pero ¿qué pasa con los equipos que trabajan juntos en un mismo proyecto? Veamos como publicar un proyecto de bazaar:
El trabajo en equipo se basa en tener un branch principal en un servidor y publicar o descargar de este repositorio.
Bazaar nos ofrece el comando push para exportar nuestro branch a un repositorio, usando
# bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject
podemos publicar a un servidor sftp y sera creado un branch que podemos usar de principal en dicho servidor. Y cualquiera con acceso al sftp puede descargarse el branch con:
# bzr branch http://www.example.com/myproject
Hasta ahora es muy cómodo el desarrollo, mantenimiento, publicación e importación de repositorios.
# bzr merge
Nos permite actualizar nuestro branch local con los cambios del branch principal (el ultimo usado con push o branch), podemos chequear los cambios con diff y si nos parece bien, con un commit los incorporamos a nuestro repositorio local.
Para publicar los cambios al repositorio oficial, si no es nuestro proyecto, podemos usar
$ bzr send -o mycode.patch
Para obtener un archivo patch con los cambios y luego enviarlo a quien corresponda para que los incorpore. Está bien, no es un proceso muy automatizado, pero es solo una forma, en la guia de usuario podemos ver los tipos de flujo de trabajo que podemos usar con bazaar. Básicamente son:
- Solo: para el desarrollador solitario que necesita control de versiones y publica paquetes. Se tiene un control de versiones sin setup y con control de cambios muy fácil de utilizar.
- Partner: Para trabajar al estilo peer-to-peer, con dos personas que trabajan en sus copias y hacen merge de los cambios de la otra persona cuando sea necesario.
- Centralizado: Basicamente el mismo workflow que cvs o subversion, todos los desarrolladores trabajan en el mismo branch, hacen update y luego commit para guardar los cambios en el servidor.
- Centralizado con commit local: Al trabajar de forma centralizada, se puede hacer un commit –local para guardar cambios en el repositorio local y luego enviar todo el set de cambios al repositorio centralizado.
- Descentralizado con copia principal compartida: Cada desarrollador trabaja con su copia local y luego la envian a la copia principal cuando los cambios están listos.
- Descentralizado con árbitro humano: Cada desarrollador tiene su propio branch y acceso de solo lectura al repositorio principal. Cuando un desarrollador quiere publicar sus cambios, le pide autorización al árbitro, quien debe revisar el código, y luego publica los cambios en el repositorio principal.
- Descentralizado con árbitro automátizado: Como el anterior pero una vez enviado al árbitro, éste hace un merge, compila y corre el suite de test, y el código se publica en el servidor principal si y solo si pasa todos los tests. Muy bueno para proyectos grandes y para test driven development. Si los casos de test estan bien mantenidos, este workflow garantiza mayor estabilidad y robustez del código. Bazaar provee una herramienta para esto llamada Patch Queue Manager (PQM) para hacer el trabajo de árbitro automatizado.
Ya tenemos un vistazo más general de las cosas que se pueden hacer con bazaar y parece ser una herramienta muy completa y que da muchas opciones para desarrollo. Me gustó mucho lo del PQM y la automatización de tests. Además parece flexible y configurable y promete ser una herramienta muy útil y sobre todo, facil de usar y configurar y con una gran cantidad de plugins y mucho potencial.