Control de Versiones: Manejando las diferencias entre distribuido y centralizado

VCSsDando vueltas por ahí, me entero que es muy sencillo utilizar localmente versionado de código fuente (gracias a los sistemas de control de versiones distribuidos, como por ejemplo Mercurial, GIT y Bazaar) para luego subir/actualizar los cambios a un repositorio Subversion principal. Es decir, en vez de usar los comandos svn como clientes de un servidor Subversion, es posible utilizar alguno de estos sistemas distribuidos como clientes «consumidores» del repositorio principal, para luego aprovechar sus importantes ventajas en forma local.

En principio, admito que no conozco ningún VCS distribuido, más que nada por vagancia (je), pero esto en particular sí lo necesito de vez en cuando, principalmente cuando no estoy conectado, y/o cuando los cambios que hago con respecto a trunk son profundos, llevan tiempo y quiero tener un control más «fino» en lo que hago.

A ver, habiendo nombrado primero los sistemas más conocidos (por mí), se desprende que tenemos:

  • Logo MercurialMercurial-Svn: Si bien el autor del artículo que me inspiró a escribir esto (Vadim Zeitlin, desarrollador de wxWidgets) comentaba que le gusta muchísimo Mercurial por su fácil uso, al momento de probar esta extensión para subir los cambios al servidor SVN de wxWidgets tuvo problemas de performance, uso de memoria, etc. De todas maneras, el código fuente en el repositorio de wxWidgets es bastante grandote (~330MB), así que quizás funcione bien para proyectos chicos/medianos, y más si uno ya conoce Mercurial.
  • Git-Svn: Bueno, citando nuevamente a Vadim, parece que critica un poco lo complicado de los comandos Git, sin embargo termina recomendándolo en forma rotunda por su velocidad y poca utilización de espacio extra en el disco*. Acá parece haber un tutorial cortito para utilizarlo (Google me devuelve muchísimos enlaces más por si es poco).

Git Version Control

En fin, recién me sumerjo en la lectura y experimentación de todo esto, pero para aquellos que trabajan contra un servidor SVN** y suben sus cambios con poca frecuencia al repositorio principal, «rompiendo todo» cada vez que lo hacen (guiño, guiño), me parece que esto les viene perfecto.

BazaarAdemás, tengo entendido que no es difícil usar Bazaar (por poner uno de ejemplo), y realmente está muy cool poder volver atrás en los cambios que uno hizo desde que hizo el checkout/update del SVN, mientras desarrolla, y sin tener que conectarse a Internet (VPN/SSH/etc.).

(*) Cuando el cliente de control de versiones distribuido hace un checkout del repositorio Subversion, no sólo descarga la última versión de trunk, sino que descarga todas las versiones pasadas de todas las ramas existentes, con lo cual el consumo de espacio en disco local pasa a ser un asunto importante. Git, según Vadim, parece tener poco overhead en este sentido comparado con la extensión de Mercurial.

(**) Una de las cuestiones que no le hacen perder valor e importancia a SVN es que, al ser centralizado, sigue siendo relevante en empresas que quieren tener un control más o menos estricto de su código; por lo tanto, la migración a sistemas distribuidos no siempre estará bajo su radar. Es por eso que hablo de «diferencias» en el título del post y no de una «futura migración», es decir, que los distribuidos sean los «nuevos vecinos de la cuadra» no quiere decir que vengan a reemplazar a los viejos y conocidos. 🙂

¡Saludos!


Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *