Repositorios en Subversion

Subversion es un sistema de control de versiones con la política copiar-modificar-mezclar con gran proyección en la actualidad. Por ejemplo, SourceForge (una forja de proyectos libres) utiliza Subversion como control de versiones. Gran parte del éxito de Subversion es su agilidad cuando intervienen varias personas, debido a su política, y a su flexibilidad que no lo limita a desarrollos software: es posible almacenar planos, imágenes, libros…

Pero esta flexibilidad puede volverse en contra del usuario: al crear el repositorio en su interior no existe absolutamente nada y nos encontramos ante el “síndrome de la hoja en blanco”. Para poder extraer el máximo partido a la herramienta es necesario definir una estructura de directorios en la que se almacene la información. Y hay algunas mejores que otras…

Aunque no es obligatorio, prácticamente todos los proyectos de Subversion tienen un primer nivel común. Las políticas aplicadas en este nivel proporcionan coherencia en la gestión y funcionalidades no disponibles de forma nativa. Esta estructura se compone de tres directorios (branches, tags y trunk) y una cuarta opcional (vendor). Es necesario definir cómo funcionan y se usan cada uno de ellos, cómo se gestionan múltiples proyectos… pero cuanto antes se empiece antes se acaba

Estructura o layout del repositorio

Ya se ha creado el repositorio por lo que se tiene la “hoja en blanco” en revisión 0. Es el momento de hacer el primer commit que dará lugar a la revisión 1, la más importante de todas ya que definirá el funcionamiento futuro del repositorio. Esta revisión crea la estructura raíz del repositorio y el funcionamiento global del mismo.

Tras multitud de experiencias, lo más recomendable para este primer commit es crear tres directorios o carpetas: branches, tags y trunk. Si está previsto utilizar algo desarrollado por terceras personas se debería crear un cuarto directorio: vendor.

El tronco o rama principal: trunk

Este directorio contiene la versión actual de trabajo sobre la que se realizan las modificaciones, es decir, el código/documentos/imágenes sobre las que se está trabajando en este momento.

Es la zona de trabajo habitual en la que los desarrolladores realizan sus modificaciones.

Como política adicional esta rama siempre tiene que tener algo correcto: si es un programa debe compilar, si es un documento en LaTeX debe poder convertirse… En los últimos tiempos se utilizan técnicas de integración continua para asegurar el cumplimiento de esta política.

Las hojas más importantes: tags

Cuando en la rama principal (trunk) se tiene una versión que se va a entregar al cliente habitualmente es necesario registrar cuál es para poder volver a ella en caso de problemas. Subversion no proporciona un mecanismo integrado para realizar esta tarea por lo que se surgen dos opciones:

  • Tener un fichero que almacene la versión del repositorio que debe gestionarse. Esta opción es poco recomendable.
  • “Copiar” la versión actual del trunk en la carpeta tags (svn cp repositorio/trunk repositorio/v.vv.vv).

La segunda opción es la más recomendable ya que suprime las necesidades de gestión al máximo. Además, hay que destacar que la copia no es tal ya que, al no existir modificación en el fichero, Subversion no copia los datos sino punteros para utilizar los mismos ficheros.

Aunque es posible realizar modificaciones sobre tags, se recomienda mantenerlas inmutables.

El laboratorio: branches

Cuando se quiere hacer algún tipo de prueba, trabajo que pueda corromper la rama principal o gestionar cambios en una versión vieja que está en mantenimiento se puede trabajar fuera del repositorio (poco recomendable y, dependiendo de la envergadura del trabajo, puede ser muy difícil volver a integrarlo en la principal) o utilizar una rama. El proceso habitual es copiar el trunk a una subcarpeta de branches, realizar los experimentos (subiendo las versiones necesarias) y, si son exitosos, mezclar los cambios con el trunk para seguir el desarrollo.

Estas ramas pueden crearse o destruirse según las necesidades y mezclar cambios con cualquier otra rama sin demasiados problemas. Además, la política de mantener la rama incorrupta no se aplica en las ramas lo que proporciona mayor libertad y permite usar una rama para almacenar una serie de pasos que dejarían corrupta la rama principal.

Aprovechando el conocimiento universal: vendor

Es habitual utilizar trabajo realizado por terceras personas (bibliotecas en un lenguaje de programación, un trabajo de universidad de otro compañero…) que es necesario controlar. Para integrarlas en Subversion se utilizan las ramas de proveedor.

La política de estas ramas permite almacenar el conjunto de versiones de las bibliotecas e integrarlas de forma transparente en el código propio. Además, permiten realizar modificaciones personales sobre la biblioteca e integrarlas con las futuras versiones de la misma.

La gestión se compone de los siguientes pasos

  1. Importar la versión actual:
    svn import ruta/biblioteca repositorio/vendor/biblioteca/current -m "Importar biblioteca vX.YY"
  2. Etiquetar la versión:
    svn copy repositorio/vendor/biblioteca/current repositorio/vendor/biblioteca/X.YY -m "Etiquetar biblioteca vX.YY"
  3. Integrarla en la rama principal:
    svn copy repositorio/vendor/biblioteca/X.YY repositorio/trunk/libs/ -m "Añadir biblioteca vX.YY a la rama principal"

Cuando se quiere integrar una nueva versión de la biblioteca, se modifica la versión current, se etiqueta y se utiliza svn merge para añadir los cambios.

Un caso especial son las bibliotecas ya gestionadas en un repositorio Subversion al que se tiene acceso. En este caso, si no se va a realizar ninguna modificación en el código o si se dispone de la posibilidad de modificar el repositorio externo, es posible enlazar directamente el repositorio de la biblioteca utilizando utilizando repositorios externos. En este caso, basta con definir la propiedad svn:external como

biblioteca repositorio

para que Subversion descargue el código externo de forma transparente.

Un repositorio por proyecto o múltiples proyectos en un repositorio

Esta es la duda eterna en el uso de Subversion. Existen argumentos a favor y en contra de cada una de las dos que, puestos en una balanza, no arrojan un claro vencedor. Para no alargar en exceso se expone opción que, de forma absolutamente personal, parece más útil: múltiples repositorios.

La idea es que cada proyecto tenga su propio repositorio con la estructura estándar en su raíz. De esta forma toda la información relacionada con el proyecto está controlada y gestionada con las mismas políticas, simplifica la migración y tiene un número de revisión único.

El principal punto en contra son las piezas comunes entre proyectos: ¿quién gestiona una biblioteca común a dos o más proyectos? La respuesta es sencilla: si es compartido pasa a disponer de su propio repositorio😮 Antes de que las manos lleguen a la cabeza y se inicien los gritos y la quema:

  • Si lo utilizan varios proyectos es más que probable que tenga entidad suficiente para ser un proyecto per se.
  • Se puede añadir utilizando referencias externas, por lo que el funcionamiento es completamente transparente en cualquier proyecto. Además, se simplifica su inclusión en cualquier otro futuro proyecto que lo precise.
  • Se puede definir políticas especiales adaptadas a la biblioteca, establecer un sistema de validación automática…
  • Agrupando las zonas comunes (más o menos relacionadas) de varios proyectos se creará la biblioteca reutilizable para toda la organización sin grandes esfuerzos. Esta biblioteca crecerá según las necesidades y con el esfuerzo de de todos.

Conclusión

El primer nivel de un repositorio de Subversion se compone de tres o cuatro directorios con una funcionalidad básica muy definida. En los proyectos más sencillos se utilizará la rama principal (trunk) y las etiquetas (tags) y, en los más complejos, se puede tener varias ramas de versiones en mantenimiento (branches), alguna experimental (branches) y bibliotecas de tercero integradas (vendor) o repositorios externos (svn:external).

Evidentemente, nada impide crear más ramas en ese nivel según las necesidades del proyecto. Sin embargo, es imprescindible definir para qué sirve la rama y las políticas a emplear en ellas.

La recomendación es crear al menos branches, tags y trunk y crear el resto según necesidades.

8 comments

  1. David · septiembre 24, 2008

    Oskitar!! Veo que de subversión no vas mal en conocimientos ..:P.
    1 abrazo,

    P.D. para que luego te quejes que no te posteo..:)

  2. Gregorio Osorio · febrero 5, 2009

    Buenas días Oskar.

    Antes que todo quiero decir que me pareció muy interesante y resumido este post. Quería plantear una pregunta: Es posible exportar (con todo y versiones) una instancia de un repositorio hacia otro servidor de Subversion?

    Muchas gracias por tu atención.

    • Oscar · febrero 5, 2009

      Para migrar repositorio subversion se pueden usar la pareja (svnadmin dump / svnadmin load).

      Básicamente se genera un fichero que contiene toda la información del repositorio y se utiliza para cargarla en otro repositorio cualquiera. Además, es posible filtrar algunas revisiones en el nuevo repositorio, o dividir un repositorio en dos…

  3. Laura · mayo 7, 2009

    Hola estoy investigando si es posible crear mas de un repositorio de carpetas en un mismo servidor apache, que apunte a una direccion diferente, alguin sabe si es posible??

    De antemano gracias!!
    Saludos!!

    • Oscar · mayo 7, 2009

      Si no lo he entendido mal la idea es servir dos repositorios de subversion en apache en dos urls distintas. Para ello basta con configurar cada URL indicando que sirva el repositorio adecuado o crear una estructura del tipo:

      svn/
      repositorio1
      repositorio2

      Indicando a apache que sirve el directorio svn como http://servidor/svn se puede acceder a todos los repositorios hijos como http://servidor/svn/repositorio1.

  4. Calabaza · mayo 25, 2009

    Con respecto a la sección:
    Un repositorio por proyecto o múltiples proyectos en un repositorio

    Yo quisiera agregar un punto a favor de múltiples proyectos en un repositorio:

    El aspecto administrativo del repositorio, el administrador solamente deberá crear una vez las cuentas que accederán a cada a cada uno de los proyectos dependientes de este repositorio ya que en el otro caso, cada vez que se empiece un nuevo proyecto se deberá crear las cuentas y cuando estamos hablando de muchos desarrolladores la cuestión creo que se vuelve bastante engorrosa.

    Me gustaría saber tu opinión sobre ese aspecto.

    El artículo está estupendo, gracias!

    • Oscar · mayo 25, 2009

      El tema de repositorio múltiple/único no tiene una respuesta o solución única y depende de cada caso particular.

      Desde mi experiencia, tener un único repositorio parece que simplifica la gestión desde el punto de vista del administrador pero nada más lejos de la realidad.
      El problema surge cuando, en un repositorio para múltiples proyectos, hay que dar permisos por cada proyecto individual: el problema se mantiene.

      Además, ahora no está claro qué versión de qué proyecto usamos (el número de versión es único por repositorio no por proyecto)….

      Lo de asignar permisos para múltiples proyectos y repositorios es sencillo de resolver: hay que usar una BBDD de autenticación única y grupos.

      Al repositorio (configuración apache o permisos del sistema de ficheros) se le otorgan permisos para el grupo svn-repositorio. Ahora, sólo hay que mantener la lista de usuarios que pertenecen al grupo.

  5. Pingback: Subversión: Gestión de directorios. « Talueee's Blog

Los comentarios están cerrados.