Disponer de control de versiones en un proyecto de desarrollo de software siempre es interesante. Hace algún tiempo que utilizo sistemas de control de versiones centralizados tipo cvs o svn; ya hasta estos días he estado muy satisfecho con ellos. Personalmente no he tenido que enfrentarme a la administración de estos sistemas; de alguna manera estaban disponibles en los proyectos en los que he participado; pero incluso si hubiera tenido que enfrentarme a administrar alguno de ellos no creo que hubiera tenido demasiados problemas. Tampoco he tenido que hacer un merge bien hecho, que es lo que tengo entendido que es más complicado.

El cambio comenzó cuando en septiembre tuve la oportunidad de asistir a las II Jornadas de Software Libre de la Universidad de La Laguna. Jonathan Riddell estuvo aquí y nos explicó muy de pasada que existía una cosa llamada bazaar (bzr) que era la que utilizaban los proyectos alojados en launchpad. Luego vi este vídeo en el que Linus Torvalds, que de gestionar proyectos grandes algo debe saber a estas alturas, hablar de algo llamado Git que es otro sistema de control de versiones distribuido.

La verdad es que soy bastante cabezón, así que no terminaba de verlo claro. Estos días he estado jugueteando un poco con bzr en el proyecto unidistro, y me ha sorprendido lo sencillo que es hacer algunas cosas que a mi no me resultaban sencillas en concepto.

Cuando trabajas en svn o cvs tiendes a implementar funcionalidades nuevas y luego comitearlas cuando están con un comentario como “La nueva funcionalidad puturru”. En bzr, como cuando comiteas lo haces en tu copia local, puedes ir comiteando cada cosa que vas haciendo sin molestar al resto de desarrolladores, cuando la funcionalidad está lista haces un push y con esto se transmite el historial de cambios, así que tendras un log con pelos y señales de qué fue lo que fue cambiando el desarrollador.

Al ser un sistema distribuido, el esquema de trabajo lo defines tu, no el sistema de control de versiones. Si en svn quieres que alguien participe en el proyecto pero no confias mucho en él o va a trabajar en una funcionalidad nueva diferente al resto le haces un branch, le das permisos sobre dicho branch y rezas para que cuando tengas que hacer un merge del branch no pierdas el coco. Esto es así porque si no le haces un branch el nuevo desarrollador no va a tener control de versiones. En bzr simplemente dejas que él haga un branch de la rama principal y que haga lo que quiera con ella,puesto que tiene control de versiones, pero es que además él puede ir haciendo merge de cualquiera de las otras ramas públicas y cualquier puede hacer merges de su rama también (si está publicada).

Disclaimer: Hablo de bzr porque es el que he probado. Probablemente Git u otros sistemas distribuidos sean tan buenos o mejores que este.

Anuncios