De Subversion a Git

Llevo años utilizando algún tipo de sistema para la administración de cambios. Desde mi primer acercamiento a la materia con Visual Source Safe, pasando por CVS, luego dándole preferencia a Subversion y recientemente decidí cambiar a Git. A continuación explico las razones por las que decidí explorar otras alternativas, porque opté por Git.

Desarrollo de Software Esbelto o haciendo software en tiempos de crisis

Una de las premisas de la manufactura esbelta que se han trasladado al desarrollo de software es la de la eliminación de aquellas actividades o consumo de recursos que no aportan valor al producto final. Esta práctica ha tomado mayor relevancia en la actualidad debido a la crisis que se vive y a la necesidad de hacer más con menos.

Para los proyectos en los que participo había estado utilizando repositorios de Subversion con tres proveedores (assembla.com, repositoryhosting.com, xp-dev.com) evitando las complicaciones administrativas de mantener un repositorio de Subversion, aún y cuando soy el único programador en la mayoría de los casos. Sin embargo, el inconveniente es que Subversion requiere conexión al repositorio para prácticamente todas las operaciones, por lo mismo puede resultar muy tardado dependiendo del enlace, especialmente las operaciones que envían datos al repositorio a través de un enlace asíncrono (Alta velocidad de recepción/Baja velocidad de envío), entiéndase todos los enlaces domésticos.

Entonces decidí explorar alternativas que hicieran más eficiente la operación de un sistema de gestión de cambios y de esta manera reducir los tiempos de espera. Fue entonces que investigué acerca de los sistemas de gestión de cambios distribuidos como Git, Bazaar, y Mercurial.

Sistemas de gestión de cambios distribuidos

La principal diferencia entre Subversion y Git, es que el primero pertenece a la categoría de Sistemas de Gestión de Cambios Centralizados y el segundo a la categoría de Sistemas de Gestión de Cambios Distribuidos. En el esquema centralizado, los meta-datos y la historia se almacenan en un repositorio central (servidor) y los clientes se conectan a ese servidor central para enviar sus cambios y obtener la versión deseada (por lo general la última) del repositorio.

Por otra parte, en el esquema distribuido cada copia del repositorio contiene toda la historia y todos los meta-datos. Ya no es necesario un servidor central para que funcione el repositorio. La principal ventaja es la velocidad, pues ya no se requiere comunicarse con el servidor central a través de la red para realizar las operaciones comunes.

Todavía se puede mantener un repositorio principal para efectos administrativos, a partir de ese repositorio principal los participantes de un equipo de desarrollo pueden obtner una copia (clonar el repositorio) y colaborar entre sí (compartir modificaciones entre sus propios repositorios) y una vez que se ha concluido, enviar las modificaciones al repositorio principal, ya sea a través de parches (archivos diff) o mezclando las modificaciones y copiando la historia de los repositorios locales.

Consumo de espacio (Tu repositorio a dieta)

Otro factor que influyó en la decisión, fue el espacio que consume el repositorio. En mi caso, un repositorio que en Subversión ocupaba alrededor de 80 MB, en Git se redujo a 28 MB. Sin embargo esto puede variar considerablemente, por ejemplo si almacenan archivos binarios (imágenes, ejecutables, etc.), en Git estos pueden consumir mucho espacio rápidamente, ya que no puede grabar las diferencias únicamente, y en la mayoría de los casos no se pueden comprimir (archivos JPEG por ejemplo).

Mire m'ijo, algún día, todo este repositorio será suyo...¿Y las herramientas apá?

Aún cuando las herramientas disponibles para trabajar con Git en Windows no tienen la madurez de las disponibles para Subversion, son aceptables y quien se sienta agusto en la línea de comandos quedará más que satisfecho, pues Git como Subversion tienen como interfaz nativa la línea de comandos.

Dicen que Mercurial tiene mejores herramientas para Windows, no me consta. No utilicé Mercurial, porque Git aunque más complicado, es más flexible. Tal vez, un día de estos experimente con Mercurial y les platico. Bazaar sólo lo he utilizado para obtener directamente código de proyectos como MySQL y OpenERP. No lo utilicé, porque simplemente los servicios que utilizo para hospedar mis repositorios privados no ofrecen Bazaar. Eso sí, si algún día deciden colaborar en proyectos de software libre tales como: Ubuntu, MySQL, Inkscape, OpenERP o Bugzilla, pues van a tener que utilziar Bazaar.

Conclusión

Los sistemas más populares son Subversion, Git y Mercurial, en ese orden. Las principales ventajas de utilizar Git son: velocidad, consumo de espacio, flexibilidad. La mayor desventaja es cambiar la manera de pensar y trabajar con tu sistema de gestión de cambios distribuido. En mi caso particular, la era de Subversion y en general de los sistemas de gestión de cambios centralizados está terminando. De ahora en adelante, utilizaré sistemas de gestión de cambios distribuidos, de preferencia Git, aunque aún me falta experimentar con Mercurial.