Estableciendo un repositorio subversion local como backup del principal

Recapitulando

Hemos estado siguiendo desde el primer artículo de este blog, el proceso que he seguido para ir modernizando los procesos productivos de la empresa donde trabajo y automatizar gradualmente el trabajo del día a día.

Tras instalar el servidor de desarrollo, denominado Goldberg, lo configuramos para conectarse via ssh sin usar contraseña al servidor contratado por la empresa en Dreamhost.

Es en Dreamhost donde se encuentran los repositorios subversion de los proyectos. El control de versiones del código es esencial para la salud del programador; podría contar la infinidad de veces que eso me permitió deshacer algún cambio que produjo más problemas que soluciones, o que me permitió ahondar en la posible fuente de algunos bugs, así como permitir el trabajo compartido en el mismo código evitando las miradas asesinas porque alguién sobreescribió los cambios de otra persona (algo que suele suceder cuando todo el mundo trabaja sobre la misma carpeta compartida en los mismos ficheros).

Objetivos

Nuestro objetivo es establecer la configuración de trabajo del control de versiones:

• Repositorios principales situados en Dreamhost, para que cualquier miembro de la empresa pueda acceder desde cualquier punto (yo a veces trabajo desde casa, por ejemplo)
• Tener una réplica de esos repositorios en el servidor de desarrollo local, tanto como copia de seguridad como para si cae la conexión en Dreamhost poder seguir trabajando con el local.

Configuración de los repositorios en Dreamhost

Crear un repositorio en Dreamhost es sencillo, no tienes más que utilizar la opción Subversion del menú Goodies, situado a la izquerda en el panel de control.

La convención que seguimos para la nomenclatura de los proyectos es asignarles un id formado por un nombre fácil de recordar, que puede ser simple o formado por palabras compuestas, unidas con o sin carácter subrayado, somos bastante flexibles al respecto. Ese id lo utilizaremos más adelante tanto para los repositorios locales como para los servidores virtuales del apache y la nomenclatura de las bases de datos.

Una vez creado el repositorio en Dreamhost, desde una consola seguimos la convención tradicional de crear tres carpetas principales, trunk, tags y branches. El por qué de esas carpetas y cual es su uso determinado es un poco largo de explicar aquí, en algunos proyectos son útiles y en otros solo usarás el trunk y no te complicarás la vida. A nivel personal, yo he tenido que usar el modelo completo de carpetas. Para una explicación más detalla, puedes googlear un poco o leerte el libro Pragmatic Version Control using Subversion, 2nd Edition. Aún así, si estás muy interesado en saber más, también puedes preguntarme ;-).

Cuando creamos el repositorio en Dreamhost, pasados unos minutos (depende de como esté de cargado el servidor) ya estará listo para su uso. Te llegará un mail notificándotelo. Para el siguiente paso, podemos hacerlo desde un acceso ssh al servidor de desarrollo (Goldberg), o desde nuestra propia máquina abriendo una ventana de terminal, en cuyo caso tenemos que tener instalado el Subversion en nuestra máquina, en el caso de trabajar en Linux instalar el paquete subversion; en un Mac, podemos instalarlo a través del MacPorts, en el caso de Windows, bueno, mejor cambia de entorno de desarrollo, para un programador no es el óptimo.

Asumiendo un proyecto que hemos identificado como prueba, ejecutamos:


svn mkdir --message "Initial project layout" http://misvn.dreamhosters.com/prueba/trunk http://misvn.dreamhosters.com/prueba/branches http://misvn.dreamhosters.com/prueba/tags


El mensaje de creación inicial puedes ponerlo en español, si quieres ("Estructura inicial del proyecto"), e incluso puedes poner lo que quieras, yo suelo seguir esa convención. Generalmente tanto los mensajes del repositorio como los comentarios del código suelo escribirlos en inglés, por eso de ser casi un estándar en el mundo de la programación en internet, aunque el código que muestre en este blog siempre estará en español.

A partir de aquí, lo siguiente que hacemos es hacer un checkout de la carpeta trunk, y añadir los ficheros iniciales del proyecto, pero todo el proceso de generación inicial del proyecto lo veremos en otro artículo, para centrarnos en el aspecto de la sincronización del control de versiones.

Instalación y configuración del repositorio en el servidor de desarrollo local

El Subversion puede utilizarse como servidor directamente, por medio del proceso svnserve, pero ya que tenemos un Apache instalado es más cómodo y práctico utilizar éste para recibir las peticiones.

Si has seguido la serie de artículos desde el principio, ya habrás instalado los paquetes necesarios, si no, has de instalar el servidor Subversion y la librería necesaria para servir los repositorios a través del Apache. En cualquier caso, el comando para hacerlo sería:

sudo apt-get install subversion libapache2-svn

A continuación, creamos la carpeta donde se alojarán los repositorios locales:

sudo mkdir /var/subversion

Para cada proyecto, crearemos el repositorio, siguiendo con el ejemplo de nuestro proyecto prueba:

sudo svnadmin create /var/subversion/prueba
sudo chown -R www-data:www-data /var/subversion/prueba

Hay que habilitar cada usuario y asignarle una contraseña (ejemplo para el usuario eddy):

sudo htpasswd -c /etc/subversion/passwd eddy

Por último, hay que editar el fichero /etc/apache2/apache2.conf y añadir lo siguiente (tras lo cual reiniciaremos el Apache):

<Location /svn>
DAV svn
SVNParentPath /var/subversion
SVNListParentPath On
AuthType Basic
AuthName "Texto que quieras aquí"
AuthUserFile /etc/subversion/passwd
<limitexcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>


Una vez se hayan importado los repositorios, se puede conectar desde cualquier máquina cliente usando como url http://goldberg/svn/prueba

Volcado de repositorios desde Dreamhost a Goldberg

Vamos a conectarnos al servidor remoto (Dreamhost) para volcar los repositorios, luego los bajaremos via sftp y los cargaremos. Veremos primero la forma manual de hacerlo, y en el próximo artículo veremos un pequeño script en Ruby que nos automatizará esta tarea.

Lanzaremos una terminal para ejecutar los siguientes comandos:

ssh nuestrousuario@nuestroservidor.dreamhost.com

Una vez conectados a Dreamhost, para cada proyecto volcamos su repositorio en un fichero. Para nuestro proyecto denominado prueba:

svnadmin dump svn/prueba > prueba.svndump

El nombre del fichero no tiene por qué acabar en .svndump, esa es una convención que sigo yo. Por otro lado, comentar que este comando vuelca todas las revisiones del proyecto. Es más conveniente volcar solo las revisiones efectuadas posteriormente a nuestro último volcado, ya que esta es una operación que haremos periódicamente, utilizando para ello los modificadores al comando dump, --incremental y --revision <num>:<num>, donde num es el número de revisión (inicial y final). De esto hablaré en el próximo artículo cuando veamos el script para realizar esto automáticamente.

Una vez generados los volcados, los descargamos por sftp en una carpeta de Goldberg. Accedemos via ssh a Goldberg y accedemos a la carpeta donde hemos descargado los ficheros volcados, y para cada uno de ellos lanzamos el siguiente comando para cargarlo en nuestro repositorio local. En el caso del proyecto prueba:

svnadmin load /var/subversion/prueba < prueba.svndump

El comando svnadmin load carga un fichero de volcado de un repositorio en el repositorio local.

Notas

Existe otra forma de sincronizar los repositorios, mediante el svnsync, que sincroniza automáticamente los cambios. El problema es que el repositorio local que se sincroniza es de solo lectura, y nosotros queríamos usar el local no solo como copia de seguridad, sino como repositorio secundario en caso de que fallase la conexión con el mundo exterior o incluso posteriormente si queremos usar solo el local.

Conclusion

Una vez establecidos repositorios arriba y abajo, lo siguiente será automatizar el procedimiento de actualización de los repositorios, ya que realizar las cargas y volcados manualmente conlleva un coste muy alto: ¡imagina lanzar todos esos comandos aunque solo sea una vez al día cuando tienes 20 proyectos en marcha! Pero eso lo veremos en el próximo artículo.