By Jose Antonio Cely Saidiza
Introducción:
No, no es nada subversivo, no se alarmen!!!, es un sistema de control de versiones, es como una especie de sistema de archivos.
Subversion esta muy bien documentado http://svnbook.red-bean.com/es/1.1/ y en español, este minitutorial/relato es para los no tienen ni idea de que es un repositorio, que nunca usaron CVS y a lo mejor ni tienen idea de que es CVS, este tutorial no es mas que un resumen del manual oficial de subversion, con mezcla de otras Webs…
nota: Los relatos y personajes descritos en este articulo son producto de la ficción, cualquier parecido con la realidad es una desgracia
Pepito y Maria en un proyecto de software libre/open source
Pepito y Maria, son dos jóvenes programadores que deciden iniciar un proyecto, algo simple, programar una "aplicación para romper contraseñas encriptadas con md5 utilizando técnicas de programación con algoritmos genéticos con una red grid :P "… Pepito y Maria solo se ven de vez en cuando, pero aun así tienen muy bien definido las características del proyecto. Resulta que Pepito tiene unos amigos que le pueden ayudar de vez en cuando, y Maria tiene unas amigas que también están dispuestas a colaborarle, además uno de los amigos de Pepito (Gonzalito) esta interesado en la aplicación que están desarrollado, pues se las ingenio para obtener el md5 de la contraseña de su novia (tal vez debido a alguna vulnerabilidad de php-nuke), y quiere desencriptarla para poder espiar sus correos y comprobar que lo están cachoneando…
Entonces tenemos este escenario,:
Pepito & Maria -> Desarrolladores principales -> administradores
Amigos de Pepito y Maria -> Otros Desarrolladores
Gonzalito -> Usuario -> Cachón
Como todos los desarrolladores/programadores están en ubicaciones diferentes, Pepito decide montar " un repositorio" para el proyecto que puedan accederlo localmente y desde Internet. Después de googlear un poco se decide por subversion, puesto que según lee CVS esta muy obsoleto, y para colmos algunos están migrando de CVS a Subversion.
Un repositorio es una aplicación que ayuda en este caso a los programadores a centralizar y coordinar sus archivos, puede servir para almacenar no solo código fuente, también se puede llevar el control a todo tipo de archivos (imágenes, documentos de oficina, ejecutables, etc) y en este momento se me ocurren aplicaciones corporativas… mmmm …
En este caso Pepito y Maria serán los administradores, se encargaran de dar permisos, resolver conflictos, crear usuarios, etc
Del manual oficial de subversion tenemos:
" Lo que hace especial al repositorio de Subversion es que recuerda cada cambio jamás escrito en el: cada cambio a cada archivo, e inclusive cambios al árbol de directorios mismo, tales como la adición, borrado y reubicación de archivos y directorios….
… permite recuperar versiones antiguas de sus datos, o examinar la historia de cómo han cambiado (sus datos). En este aspecto, mucha gente piensa en los sistemas de versiones como en un tipo de "máquina del tiempo".
Llego la acción, configurando el servidor he iniciando el repositorio
Subversion funciona en cualquier sistema operativo donde corra el servidor web Apache: BSD, Linux, Mac OS X, Netware, Windows, etc. Pepito tiene conexión a Internet permanente en un servidor con Debian Sarge, con apache2 recién instalado, para instalar el servidor subversion sencillamente hay que ejecutar el comando:
#apt-get install subversion subversion-tools libapache2-svn
Pepito dice: "Joder, apt-get es una maravilla, lo instalo todo de zopeton, y resolvió dependencias automáticamente!!!", para usuarios de otras distribuciones o sistemas operativos que no tengan la suerte de Pepito, pueden buscar como configurarlo en su sistema operativo, o si lo prefieren pueden bajarse el código fuente y compilarlo.
Una vez instalado, vamos a crear una carpeta para almacenar nuestro repositorio:
# mkdir -p /var/local/repos
Ahora creamos la base de datos del repositorio (mas información abajo):
# svnadmin create /var/local/repos
Ahora permitimos al servidor web escribir en el repositorio
# chown -R www-data:www-data /var/local/repos
nota: "www-data "es generalmente el usuario en que corre el servidor web en Debian, en otras distribuciones puede variar, por ejemplo en fedora el usuario es "apache".
Ahora vamos a configurar Apache para permitir el acceso al repositorio via http (web).
en el archivo /etc/apache2/httpd.conf añadimos:
<Location /repos>
DAV svn
SVNPath /var/local/repos
AuthType Basic
AuthName "Repositorio Subversion en labs.tecsua.com"
AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Ahora creamos el archivo de autenticación, en este archivo se guardaran todos los usuarios:
#htpasswd2 -c /etc/subversion/passwd pepito
Nótese que el comando "htpasswd2" tiene la bandera "-c", por lo que es la primera vez que se ejecuta el comando la bandera "-c" crea el archivo en caso de que no exista, pero si ya existe lo sobreescribe, para añadir nuevos usuarios, ya no tenemos que especificar la bandera "-c"… entonces el comando para añadir el usuario Maria es:
#htpasswd2 /etc/subversion/passwd maria
Por ultimo, reinicie Apache2 con el comando (para Debian):
#/etc/init.d/apache2 restart
Listo!!!, ahora Pepito y Maria podrán acceder al nuevo repositorio de subversion
http://<nombre_máquina>/repos por ejemplo http://192.168.0.1/repos
Vía web podremos ver la Revision 0: /, es un buen momento para festejar e ir por una cerveza para continuar el trabajo
Trabajando con subversion
Pepito va a crear la estructura de directorios para su proyecto, para esto seria mejor que cumpliera algunos estándares (Pepito es un buen programador, por lo tanto cumple estándares).
Después de hablar con Maria deciden montar la estructura para dos proyectos, el rompe md5 y una aplicación empresarial que esta desarrollando Maria.
Pepito escoge un directorio o carpeta para trabajar con el repositorio, se ubica en ella y ejecuta el comando:
#svn checkout http://192.168.0.1/repos
De esta forma se conecta vía http al servidor subversion y obtiene la revision 0. Que es esto de la revision?, por el momento podría decir que es como una instantánea de los archivos en el repositorio, por cada cambio que se haga en el repositorio (Eje. añadir, eliminar, modificar archivos), el repositorio crea un numero de revisión, que es un numero entero que automáticamente se incrementa por cada cambio que se suba al servidor, con este numero de revisión es que podremos "regresar en el tiempo" a un estado del repositorio anterior.
La manera estándar recomendada para organizar un repositorio es crear un directorio trunk que contiene la "línea principal" de desarrollo, un directorio branches que contiene copias de las ramas, y un directorio tags que contiene copias de las etiquetas.
Directorios:
/trunk
/branches
/tags
Como en el repositorio de Pepito y Maria se van a almacenar dos proyectos, Pepito elije un directorio en su carpeta de usuario y ahí hara el desarrollo del proyecto, es decir es su copia local, en la cual podrá hacer y deshacer, sin afectar al repositorio del servidor a menos que haga un "commit", pero ya profundizaremos en eso… por ahora Pepito creara la siguiente estructura de directorios dentro de algún directorio que escogió para trabajar.
Dentro de su copia de repos crea la siguiente estructura
…./rompemd5
…./rompemd5/trunk
…./rompemd5/branches
…./rompemd5/tags
…./empresarial
…./empresarial/trunk
…./empresarial/rompemd5/branches
…./empresarial/rompemd5/tags
En este momento hay una diferencia entre el repositorio del servidor y la copia local de Pepito (la diferencia son los directorios creados), entonces es el momento que Pepito haga un "commit".
Con el comando svn add, podemos agregar archivos y directorios (de forma recursiva por defecto) a nuestra copia del repositorio, nótese que dije "nuestra copia del repositorio", no dije "al repositorio", lo que sucede es que cuando Pepito ejecuto el comando svn checkout obtuvo una revisión en la que no existían los directorios que comentábamos antes, entonces con svn add los pegamos a nuestra copia local.
El comando seria:
# svn add archivos_o_directorios_a_agregar
Esta es la salida del comando de Pepito
# svn add rompemd5/ empresarial/
A rompemd5
A rompemd5/trunk
A rompemd5/branches
A rompemd5/tags
A empresarial
A empresarial/branches
A empresarial/trunk
A empresarial/tags
Otros comandos útiles son svn delete, svn copy, svn move, vale la pena decir que nada es borrado totalmente del repositorio, solo del la revisión actual del repositorio. Se puede conseguir cualquier cosa que se borró descargando (o actualizando su copia de trabajo) a una revisión anterior a la que lo borró.
Con el comando commit del svn se suben los cambios al repositorio.
# svn commit
Después de ejecutarlo se abrirá el editor vi u otro para escribir comentarios acerca de los cambios hechos, Pepito procura siempre ser lo mas descriptivo en los comentarios, para facilitar mas el seguimiento y manejo al repositorio.
Como es la primera vez que hacemos un "commit", nos pedirá nuestra contraseña de usuario en el repositorio.
esta es la salida del comando de Pepito:
#svn commit
Reino de autentificación: Repositorio Subversion en labs.tecsua.com
Clave de ‘Pepito’:
Añadiendo rompemd5
Añadiendo rompemd5/branches
Añadiendo rompemd5/tags
Añadiendo rompemd5/trunk
Añadiendo empresarial
Añadiendo empresarial/branches
Añadiendo empresarial/tags
Añadiendo empresarial/trunk
Commit de la revisión 1.
Joder!, se ha hecho el primer "commit", se han subido cambios al servidor, el numero de revisión se incremento en uno, es el momento de otra cerveza!!!
Después de beberse dos cervezas, Pepito ejecuta los siguientes comandos
# cd rompemd5/
# vi README.txt
# vi ../empresarial/README.txt
# cd ..
Con esto Pepito creo los clásicos archivos README.txt dentro de los directorios nuevos.
Esto es un nuevo cambio, por lo tanto es necesario otro commit para que se vea reflejado en el servidor, antes de esto Pepito ejecuta el comando svn update que le actualizar cambios entre el servidor y su copia, ahora es buena costumbre hacer este comando siempre antes de cualquier commit, por que le permite actualizar sus cambios con los que han hecho otros usuarios mas adelante profundizaremos en esto.
Esta es la salida del comando:
#svn status
? rompemd5/README.txt
? empresarial/README.txt
La primera columna, de una sola letra dice el estado de un archivo o directorio y/o su contenido. Los códigos impresos son:
A el archivo o directorio ha sido programado para la adición en el repositorio.
C el archivo o directorio está en un estado de conflicto. Debe resolver este conflicto antes de enviar sus cambios al repositorio.
D el archivo o directorio ha sido programado para borrarse del repositorio.
M el contenido del archivo ha sido modificado.
X el directorio está sin versionar, pero está relacionado con una definición externa de Subversion.
? el archivo o directorio no está bajo control de versiones.
En el caso de Pepito esta el signo ?, que significa que son dos archivos que no se han añadido al repositorio local, puesto que fueron creados a mano, entonces el paso a seguir es ejecutar svn add.
# svn add rompemd5/README.txt empresarial/README.txt
A rompemd5/README.txt
A empresarial/README.txt
Si ahora ejecutamos svn status, el símbolo ? ha cambiado por A que significa que los archivos README.txt se han pegado al repositorio local
#svn status
A rompemd5/README.txt
A empresarial/README.txt
Ahora si es el momento de hacer el segundo "commit".
Pepito ejecuta el comando svn commit:
#svn commit
Añadiendo rompemd5/README.txt
Añadiendo empresarial/README.txt
Transmitiendo contenido de archivos ..
Commit de la revisión 2.
Joder!, se ha hecho el segundo "commit", el numero de revision se incremento en uno, es momento de mas cerveza!!!
En este momento Pepito llama a Maria y le comenta que ya esta funcionando el repositorio, que puede acceder desde Internet, sincronizar el repositorio y empezar a trabajar en el proyecto, Maria no puede del asombro, bota el teléfono y sale corriendo a su computador (que también tiene Debian Sarge), e instala subversion con el comando apt-get install subversion, pero nada mas para acceder como cliente, después de instalado, Maria crea un directorio dentro de su directorio de usuario que de ahora en adelante sera en el que va a trabajar, una vez dentro del directorio ejecuta el comando:
#svn checkout http://dominio-de-pepito.com/repos
A repos/rompemd5
A repos/rompemd5/trunk
A repos/rompemd5/branches
A repos/rompemd5/README.txt
A repos/rompemd5/tags
A repos/empresarial
A repos/empresarial/trunk
A repos/empresarial/branches
A repos/empresarial/README.txt
A repos/empresarial/tags
Checked out revision 2.
El mismo comando que ejecuto Pepito al principio, ahora Maria tiene su copia local, emocionada, llama a su amigas por teléfono para contarles, a diferencia de Pepito que bebía cerveza :D.
Ahora Gonzalito puede acceder anónimamente con el mismo comando #svn checkout http://dominio-de-pepito.com/repos/rompemd5/trunk y obtener siempre las ultimas versiones de la aplicación que están desarrollando, con la esperanza de algún día poder bajarse una versión con la que por fin pueda romper la contraseña md5 que tiene de su novia.
Trabajando en equipo y de vez en cuando resolviendo conflictos
Maria después de analizar los archivos añadió unas lineas al archivo README.txt del directorio ….repos/rompemd5, hizo un commit, ahora la revision es numero 3, entonces cuando Pepito ejecute el comando svn update producirá el siguiente resultado:
# svn update
U rompemd5/README.txt
Actualizado a la revisión 3.
Joder!, los cambios de Maria fueron automáticamente reflejados en su copia local, solo descargo el archivo modificado, y automáticamente se actualizo a la revision 3.
En el resultado del comando, la primera columna, de una sola letra dice el estado de un archivo, los códigos impresos son:
U los archivos marcados con una U no contienen cambios locales pero fueron actUalizados con cambios del repositorio
G merGed, lo que significa que el fichero tenía para comenzar cambios locales, pero los cambios que venían del repositorio no se solaparon de ninguna manera.
C conflicto. Esto significa que los cambios del servidor se solapan con los suyos propios, y ahora tiene que elegir manualmente entre ellos.
Otro comando útil es svn diff, produce una salida comparando sus ficheros de copia de trabajo contra la copia "virgen" almacenada en el directorio oculto .svn.
Después de un tiempo corto de trabajo Maria edita nuevamente el archivo README.txt, en la segunda linea donde aparecía una fecha, y al mismo tiempo Pepito modifico el mismo archivo, en la misma linea, pero escribió la fecha en un formato diferente, Maria hizo un "commit" primero que Pepito, entonces cuando Pepito ejecute svn update, obtendra un conflicto. Esta es la salida del comando:
# svn update
C rompemd5/README.txt
Actualizado a la revisión 6.
La C indica un conflicto, por lo tanto su subversion no permitirá el commit de ese archivo hasta que el conflicto sea solucionado.
Por cada archivo en conflicto subversion crea tres archivos mas en su copia local.
nombre_de_archivo_en_conflicto.mine El archivo como existió en su copia de trabajo antes de que se actualizara en su copia de trabajo, osea, sin marcas de conflicto. Este archivo tiene su últimos cambios y nada más.
nombre_de_archivo_en_conflicto.r_anterior El archivo que era la revisión BASE antes de que se actualizara su copia de trabajo. osea, el archivo que usted descargó antes de que hiciera su última edición.
nombre_de_archivo_en_conflicto.r_nueva Es el archivo que su cliente de Subversion recibió del servidor justo cuando se actualizó su copia de trabajo. Este fichero corresponde con la revisión HEAD del repositorio.
En el caso de Pepito los archivos son los siguientes:
# ls -l README.txt*
README.txt
README.txt.mine
README.txt.r5
README.txt.r6
Pepito necesita hacer una de estas tres cosas para solucionar el conflicto de archivos:
* Fusionar el texto en conflicto "a mano" (examinando y editando las marcas de conflicto dentro del archivo).
* Copiar uno de los archivos temporales sobre su archivo de trabajo.
* Ejecutar svn revert <nombre_de_archivo> para eliminar todos sus cambios locales.
Después de hablar con Maria por teléfono, llegan a un acuerdo en el formato de las fechas, Pepito decide darle la razón a Maria y tomar los cambios de ella, entonces ejecuta el comando:
# svn revert README.txt
Se revirtió ‘README.txt’
Después ejecuta:
# svn resolved README.txt
Y subversion elimina automáticamente los anteriores archivos generados por el conflicto y subversion no considerara el archivo README.txt en conflicto.
Por el momento es el fin de este relato…
Y así fue como Pepito y Maria pudieron iniciar y trabajar eficientemente en su proyecto, gracias a subversion y al software libre/open source pudieron montar su propio repositorio en Internet, ahora están recibiendo ayuda desde todas partes del mundo, y todos sus usuarios (eje. Gonzalito) pueden bajar las ultimas versiones de sus aplicaciones.
FIN
Este relato/tutorial es producto de un Domingo desocupado, sin bañarme y después de casi 20 horas frente a computadores e Internet, cuando avance un poco mas en mis conocimientos básicos de subversion, prometo publicarlos en este weblog, con la segunda parte de esta historia, en la que Pepito se vuelve alcohólico, Gonzalito rompe el md5 de la contraseña de su novia, y mucho mas en… " Pepito y Maria revolutions " … :D …
Dudas, comentarios, sugerencias?
Links:
http://svnbook.red-bean.com/es/1.1/
http://www.macprogramadores.org/beos/tutoriales/THD/herramientasgnu/repositorios/intro.html
http://qref.sourceforge.net/Debian/reference/reference.es.txt
http://www.lugmen.org.ar/proyectos/desarrollo/material/faq-subversion.html
© José Antonio Cely Saidiza – 2005 jose.cely@tecsua.com
Consultor, unixero, desarrollador.