Subversion, instalación, configuración y uso en Debian

, por laura

Aunque hay un trillón de páginas en internet que hablan sobre cómo instalar y configurar un servidor svn, no todas reproducen el proceso completo, así que para cada paso hay que ir saltando de link en link hasta más o menos tenerlo todo listo, así que por eso he intentado reunir todos los pasos aquí.

Control de versiones

Para llevar un control de los cambios que se realizan en el código fuente al desarrollar una aplicación, se suelen usar sistemas de control de versiones.
Estos sistemas pueden ser usados por varios usuarios/desarrolladores al mismo tiempo, ya que éstos se conectan a un servidor central donde se guarda el repositorio que contiene el código fuente original y los cambios que se van haciendo, junto con todos los datos necesarios para conocer quien, cómo y porqué alguno de los usuarios ha realizado un cambio.
De este modo el desarrollo de la aplicación es mucho más ordenado y sobretodo sencillo porque estos programas permiten volver a una versión anterior y así poder deshacer los errores que pueden aparecer en el avance de la programación.

Subversion

Aunque hay otras aplicaciones disponibles, uno de las mejores actualmente, o eso dicen, es Subversion, también conocida como svn.

El svn tiene una arquitectura cliente-servidor con controles de concurrencia para cuando varios desarrolladores estan trabajando en el mismo archivo no se produzcan problemas, ya que está pendiente de si los cambios enviados al servidor son compatibles o no, entre sí. Subversion sirve para mantener un historial de versiones tanto en código fuente, como en páginas web o en documentación de cualquier tipo.

Funcionamiento

Al iniciar un proyecto, normalmente, se instala un repositorio SVN en el servidor central. Este repositorio tiene una estructura jerarquíca de archivos que, por ejemplo para el ProyectoA sería la siguiente:

Donde el repositorio ProyectoA contendría estas carpetas:

  • trunk: carpeta donde reside el código fuente en desarrollo.
  • branches: carpeta donde están guardadas las ramas, versiones disponibles del código.
  • tags: carpeta donde se guardan las etiquetas y nombres de ramas que se van creando.

Los usuarios, en sus ordenadores o en sus /home del mismo servidor, tendrán una copia local de la versión en desarrollo que a cada uno les interese trabajar.

En los logs del servidor svn se registran los cambios y revisiones que se generan. Es recomendable que cada cambio importante, realizado sea mandad con un breve comentario al servidor central para que este actualice el código y así siempre esté disponible para los otros desarrolladores la versión más actualizada posible.

Instalación del SVN

La instalación en sistemas de tipo Debian es muy sencilla, basta con emplear el famoso apt en una shell:

~>sudo apt-get install subversion

También podemos instalar sus herramientas:

~>sudo apt-get install subversion-tools

El svn se ha de instala de igual modo en el servidor como en los clientes, la diferencia está en que a partir de que el svn esté preparado en el servidor, el cliente, sólo, ha de conectarse a él y bajar el código para empezar a programar, pero esto se verá un poco más tarde, a continuación propongo algunas configuraciones para el servidor de svn.

Configuración

En principio, el servidor svn como tal no necesita más configuraciones, pero si se pretende usar el repositorio de forma remota se ha de usar el servidor svnserve y por lo tanto configurarlo.

Así también, en algunos manuales aconsejan crear un nuevo grupo para el svn y luego añadir algún usuario distinto de root que pueda ejecutar el servidor svnserve:

# crea un nuevo grupo llamado subversion:
~> sudo groupadd subversion

# para añadir nuestro usuario al grupo subversion:
~> sudo addgroup tu_usuario subversion

Para arrancar el demonio se ejecuta este comando:
~> svnserve -d -r /home/demo/repository

svnserve es un servidor independiente, ejecutable como proceso demonio o invocable por SSH; otra manera de hacer que el repositorio esté disponible para otros a través de una red.

La opción d es para que arranque a modo de demonio y la opción r es para que funcionen los repositorios que pudieran estar instalados por debajo del directorio repository/

Para su configuración se utiliza el archivo /repositorio/conf/svnserve.conf pero como avisa en el encabezamiento de dicho archivo si se van a usar URLs de los tipos: http:// y file:/// la configuración que se incluya en este archivo es totalmente ignorada. [1]

Todo esto para una instalación de svn en un entorno de red limitado, si se tiene un entorno más complejo, como fuera la existencia de cortafuegos, habría que abrir puertos y para permitir la comunicación con los clientes del servidor.

Creando nuestro primer repositorio en el servidor

Una vez instalado el svn podemos rápidamente crear el repositorio en algún directorio de nuestro servidor. Para ello basta con ejecutar:
~>svnadmin create /path/repositorio

Creamos un directorio temporal y entramos en él:

~> mkdir tmpdir
~> cd tmpdir

Dentro debería ir toda la estructura de directorios anteriormente comentada, así que creamos los directorios y subdirectorios:

~> mkdir proyectoA
~> mkdir proyectoA/trunk
~> mkdir proyectoA/tags
~> mkdir proyectoA/branches

Para añadir los proyectos, si se tiene un proyecto empezado, se reorganizaría en las carpetas arriba comentadas, trunk, tags, branches. Colocando todo el código de nuestro proyecto en la carpeta trunk/

Una vez creadas las carpetas y dispuesto el código, hay que llevarlo al repositorio, para que se pueda comenzar a programar a través del subversion:

~> svn import . file:///path/hasta/repositorio/proyectoA —message ’Creando el primer repositorio’

El . en el comando anterior indica que la fuente del código inicial para el repositorio está en el mismo directorio donde nos encontramos, es decir, que se halla en /tmpdir .

URLs de Acceso al Repositorio
Aunque en este artículo sólamente se usará la url del tipo file://, permite acceder a los repositorios desde disco local o mediante algunos protocolos de red, siendo siempre la ubicación de un repositorio una URL. La url del tipo file:// sólo es válida en el caso que tanto el cliente, como el servidor svn estén en el mismo ordenador instalados.

Correspondencia entre los diferentes esquemas de URL y los métodos de acceso
Esquema Método de acceso
file:/// acceso directo al repositorio (en disco local)
http:// acceso vía protocolo WebDAV a un servidor Apache que entiende de Subversion
https:// igual que http://, pero con cifrado SSL
svn:// acceso vía un protocolo personalizado a un servidor svnserve
svn+ssh:// igual que svn://, pero a través de un túnel SSH

En general, los URLs de Subversion utilizan la sintaxis estándar, permitiendo la especificación de nombres de servidores y números de puertos como parte del URL. [2]

Una vez importado el código, nos podemos deshacer del directorio temporal,

~> cd ..
~> rm -rf tmpdir/

Hasta aquí todos los pasos para que el repositorio svn sea accesible y funcional, a partir de este punto se proponen ideas para que sea más útil y agradable trabajar con el servidor svn.

Activar el módulo de Apache de Subversion

Para que se puedan mostrar los repositorios a través de la web se ha de activar un módulo especial para el caso. Lo primero instalar la librería correspondiente:

~> sudo apt-get install libapache2-svn

Para activar la nueva configuración reiniciar el servidor apache:

~> sudo /etc/init.d/apache2 restart

Normalmente tras la instalación de esta librería lo lógico es que se active el módulo requerido, pero por si las moscas, este es el comando para activarlo:

~> sudo a2enmod dav_svn

Configuración del módulo de Subversion

Para configurar este módulo se ha de editar el archivo dav_svn.conf que se encuentra en el directorio /etc/apache2/. Esta es la configuración que me ha servido para echar a andar este servicio:

<Location /svn>

DAV svn

#SVNPath, permite acceder via apache a la direccion: dominio/svn directamente

SVNPath /home/Usuario/svn

#SVNParentPath, permite acceder a directorios superiores al repositorio, si y solo si, apache tiene permisos de lectura sobre dichos directorios.

#SVNParentPath /home/Usuario/svn

# No pueden estar activados estas dos opciones ( SVNParentPath y SVNPath) simultaneamente.

AuthType Basic
AuthName "Repositorio Subversion del proyecto"
AuthUserFile /etc/apache2/dav_svn.passwd

<LimitExcept GET PROPFIND OPTIONS REPORT>

#       Require valid-user

</LimitExcept>
</Location>
      CustomLog /var/log/apache2/svn/access.log combined
      ErrorLog /var/log/apache2/svn/error.log

Tras modificar este archivo, siempre, se ha de reiniciar el servidor web, es decir, ejecutar esto:

~> sudo apache2ctl restart

Para comprobar si se puede ver el repositorio a través de la web, sólo cabe ir a un navegador y escribir la dirección correspondiente, por ejemplo:

http://dominio.que.setenga/repositorio/

Si no hay ningún problema y se puede navegar en el repositorio, ya está listo para funcionar. El único defecto es el aspecto que tiene es como mínimo decepcionante. Por fortuna, este aspecto se puede mejorar con algunos scripts que se encuentran por la red. Uno de tantos es WebSVN.

WebSVN, la nueva cara para el repositorio

WebSVN es un script que es muy fácil de instalar y muy interesante en cuanto a la información que aporta.

Su instalación, como digo, es sencilla:

- 1- descargar el websvn de su web, preferiblemente la versión más reciente :)
- 2- Se descomprime en una carpeta que sea visible a través del servidor web. (por ejemplo en /var/www/)
- 3- Buscar el archivo distconfig.php en el directorio /websvn/include/ .
- 4- Copiar distconfig.php renombrandolo como config.php
- 5- Editamos este archivo de configuración, para añadir estas líneas:

$config->addRepository('NombreRepositorio', 'file:///pathr/hasta/repositorio');

- 6- Por último, y para que los feeds rss puedan funcionar debemos darle permisos (rwx) a la carpeta cache/ que se encuentra en el directorio de websvn, haciendo:

~>chmod 0777 /.../websvn/cache

Con esto, comprobamos que al acceder a la página http://dominio/websvn/ se ve nuevamente nuestro repositorio, pero con un aspecto muy mejorado y un montón de aplicaciones, datos y facilidades que no están presentes sin el uso de este script.

SVN y sus clientes

Desde el lado del cliente-programador, las cosas son más sencillas. A partir de que el programador se haya instalado el svn, hay cientos de comandos que puede utilizar para la interacción con el svn, entre ellos quisiera descatar algunos.

Comandos útiles

  • Conseguir el código:

~> svn checkout file:///ruta/hasta/repositorio/ProyectoA/trunk /directorio/de/trabajo/ProyectoA/

  • Detecta todos los cambios de fichero y árbol que el cliente ha hecho en su copia local:

~> svn status
Véase la documentación sobre este comando para entender mejor la salida que muestra su ejecución.

  • Actualizar el código del proyecto:

~> svn update

  • Tras modificar y guardar los cambios, se envian al server:

~> svn commit --message 'comentario'

  • Añadir archivos al código:

~> svn add /archivo-N/ --force

  • Mover o renombrar archivos en la copia local:

svn move archivo_inicial   archivo_final

  • Mover o renombrar archivos en la copia del servidor svn:
svn move -m "Mover archivo" http://dominio.que.setenga/repositorio/trunk/archivo_a_modificar.h  http://dominio.que.setenga/repositorio/trunk/archivo_modificado.h

o bien moverlo a otro directorio del mismo proyecto:

svn move -m "Muevo el archivo install.php a includes/ " file:///home/Usuario/repositorio/ProyectoA/trunk/install.php  file:///home/Usuario/repositorio/ProyectoA/trunk/includes/install.php
  • Borrar archivos:

~> svn delete archivo

  • Rechazar los cambios en un archivo:

~> svn revert archivo

  • Volver a una versión anterior determinada:

~> svn update -r N

Donde N denota la revisión N que a su vez representa el estado del sistema de ficheros del repositorio tras el envío de cambios N-ésimo.

  • Ver un informe de los cambios producidor:

~> svn log

  • Fijar una versión, crear una rama, etiquetandola con un nombre sencillo:

Etiquetando la última versión:

~> svn copy file:///path/repositorio/trunk file:///path/repositorio/tags/0.01-prerelease -m "Version 0.01"

O bien especificando una revisión concreta:

~> svn copy -r 3 file:///path/repositorio/trunk file:///path/repositorio/tags/0.03-prerelease -m "Version 0.03"

  • Para hacer una copia limpia del código, y poderlo distribuir
    ~> svn export file:///path/repositorio/ProyectoA/trunk
    ~> tar -cvf proyectoA.tar trunk
    ~> gzip proyectoA.tar
  • Hacer copias de seguridad del repositorio:

~> svnadmin dump /paht/repositorio/ProyectoA | gzip -9 > dump_svn_proyectoA.gz
Si se incluye en el CRON, se harán las copias de seguridad cada tanto de una manera automática.

Conclusiones

Comentar que se pueden tener tantos repositorios como se deseen en un mismo servidor, y también se pueden tener tantos proyectos en un mismo repositorio como se necesiten, en realidad es cuestión de gustos elegir una u otra forma de administrar los repositorios, eso si, no siempre conviene tener todos los proyectos en un mismo repositorio, y a veces lo que no conviene es lo contrario.

Y por último, si es necesario borrar un repositorio por alguna razón, basta con borrar el directorio en el que se ubica en el disco duro del servidor. Eso sí, este paso no se puede deshacer ;).