Etiqueta : subversion

Instalando clientes SVN para ubuntu

Usando (aún) Gnome me he visto en la necesidad de trabajar colaborando con repositorios Subversion (SVN) y como actualmente no tengo instalado ningun IDE de desarrollo que siempre incluye las utilidades de SVN de control de versiones, me he instalado el paquete nautilus-script-collection-svn que me da justo lo que necesitaba, añadiéndome a los menus contextuales de nautilus las opciones estándar de Subversion.

Acompaño mis palabras de una imagen del nuevo menú contextual

Menú contextual de Nautilus SVN

Pero yendo un paso más allá, he encontrado otros paquetes llamados rabbitvcs* que para mi gusto ya si que me dan todas las opciones que necesito y es que me aparecen iconos asociados al estado de en subversion de cada fichero, indicándome si tengo ficheros modificados que actualizar en el servidor o si por el contrario están sin modificar.

También acompaño mis palabras de una nueva imagen para que se entienda mejor la idea que quiero trasmitir

Rabbit VCS

Me parece súper útil e intuitivo de utilizar, aún para aquellas personas que, no siendo informáticas, se sienten obligadas a usar estas herramientas de cooperación 😉

Los paquetes instalados han sido

  • rabbitvcs-nautilus
  • rabbitvcs-cli
  • rabbitvcs-nautilus

Mercurial, explicado para usuarios de Subversion

Debido a que los repositorios de Openbravo son de Mercurial, en los últimos meses me he tenido que acostumbrar con ese sistema de control de versiones (SCV).

Para alguien que sólo ha trabajado con Subversion (o anteriores), esto significa un importante cambio de filosofía, puesto que Mercurial se engloba dentro de los más modernos sistemas de control de versiones distribuidos (como Git, Bazaar y otros). Lo que voy a contar es específico de Mercurial, pero estos cambios vienen motivados por su característica de distribuido.

El principal cambio es respecto a la redifinición de los conceptos de cliente y servidor. En SVN, la separación está muy clara: el servidor aloja las versiones y se encarga de su gestión. Por otro lado, los distintos clientes se bajan copias del servidor, realizan cambios, y envían esos cambios al servidor.

SCV tradicional

En toda esta relación está claro quién es quién. En nuestra máquina local tenemos el cliente, y en el servidor el repositorio. Con Mercurial la cosa cambia mucho, porque cada copia del repositorios es a la vez cliente y servidor. En lugar de hacer checkout, para hacerte con un repositorio cliente del servidor, haces clone, con lo que creas un nuevo repositorio cliente-servidor copia del anterior. Las operaciones de commit y update funcionan en local, mientras que se introducen nuevas operaciones (pull y push) para intercambiar cambios entre repositorios. Todo junto quedaría en el siguiente esquema:

SCV distribuido

Esta estructura es bastante más compleja que un SCV tradicional, pero ofrece una serie de ventajas que compensan el aprendizaje inicial. Se suele decir que las principales ventajas son relativas a proyectos grandes, con un montón de colaboradores y varias personas validando grupos de estos colaboradores. Sin embargo, mi experiencia es que incluso cuando hay un único desarrollador, hay beneficios importantes.

Una ventaja que puede parecer secundaria, pero que a mí me encanta, es la capacidad de realizar commits locales. Esto permite trabajar con el control de versiones aún cuando no tienes acceso al servidor princiapl (circunstancia muy frecuente). Esto permite que los desarrolladores incomunicados puedan hacer commits con cambios pequeños y atómicos, en lugar de realizar un envío masivo donde todos los cambios van a tropel y hacen inmanejables logs, control de cambios y vueltas atrás.

Hablando de vueltas atrás, con Mercurial también es posible revertir cualquier fichero a cualquier revisión sin necesidad de conexión con el servidor. Los programadores que se han visto en estas situaciones adversas (como proxies) durante largos periodos pueden valorar estas ventas.

Pero quizá la ventaja más importante está en el prácticamente nulo esfuerzo requerido para clonar repositorios. Por ejemplo, cada vez que un cliente nuevo requiere una personalización de Openbravo POS, se le puede crear un nuevo repositorio simplemente clonándolo. Luego cada desarrollador clonaría de este nuevo repositorio y compartirían los cambios a partir de él.

Si es el caso de OpenTPV, la versión de Opensistemas de Openbravo POS para negocios de restauración, la estructura sería Openbravo POS -> OpenTPV -> versión del cliente . Si hay cambios en el repositorio principal de Openbravo POS, es trivial irla bajando a OpenTPV y a sus modificaciones. Si arreglamos un bug, dependiendo de la raíz del problema, podemos corregir Openbravo POS, OpenTPV o la versión del cliente, y luego difundir esos cambios a los que corresponda.

La única desventaja que le encuentro a Mercurial es que requiere algo más de control y pensar bien cómo organizar estos repositorios. En otras entradas planeo contar un poco más de esto ya que, por si no se ha notado, Mercurial me ha encantado.

Por todo esto, yo recomendaría su uso, o al menos probarlo. Quizá algún día merezca implantarlo a nivel oficial en la empresa, como alternativa al madurito Subversion.