“Subversion”

7 Ene

 

1. Concepto de Subversion

 

Subversion es un sistema de control de versiones de código abierto, de propósitos similares al bien conocido, ampliamente extendido, y obsolescente CVS. Está diseñado para proporcionar un sofisticado sistema de control de versiones, desarrollado con tecnología moderna.

Subversion está todavía en desarrollo y no ha llegado aún a la versión 1.0. Sin embargo, es bastante estable y ya se puede usar. En este artículo cubriremos los aspectos básicos de Subversion, como instalarlo, y como usar Subversion para proyectos personales.

2. Ventajas, Desventajas de Subversion

 

  • Los utilizadores pueden recuperar los datos oficiales en sus directorios de trabajo locales, editarlos, y enviarlos de regreso a la versión oficial.
  • Si dos usuarios editan el mismo archivo localmente, subversion se hace cargo de guiar la resolución de los posibles conflictos.
  • Ningún cambio se pierde. Por diseño, subversion se encargará de guardar todos los cambios que se hagan a la versión oficial.
  • Se pueden adicionar archivos de cualquier tipo (svn:mime-type).

Subversion soluciona estos problemas del CVS:

  • No registra cambios en la estructura de directorios: no es posible mover, renombrar, ni copiar. Estas operaciones se consiguen eliminando y añadiendo, pero con esto perdemos el historial de cambios. Este defecto se debe a que CVS usa internamente el sistema de almacenamiento de RCS , que solo registra cambios de contenido en ficheros individuales.
  • Es necesario interrumpir el acceso al repositorio para crear copias de seguridad.
  • No permite “conjuntos de cambios”. Cuando un desarrollador sube un conjunto de cambios, se van subiendo uno a uno, quizás al mismo tiempo que otro desarrollador hace lo mismo. Al no ser una operación atómica, nadie puede asegurar que el estado del repositorio tras su commit, sea el mismo que el estado que probó en local, y por tanto, el proyecto puede estar en un estado que nadie ha probado. Además, deshacer un conjunto de cambios requiere recorrer el repositorio entero comparando las fechas.
  • Almacena ficheros binarios enteros (no sus diferencias entre versiones). Esto consume espacio en disco y ancho de banda.
  • No usa la red eficientemente. Las diferencias entre versiones solo se envían desde el servidor al cliente, cuando el cliente sube sus cambios envía ficheros enteros.
  • El código fuente es difícil de mantener. CVS comenzó como un conjunto de scripts shell que usaban RCS e implementaban algoritmos desarrollados entre los años 60-80. El resultado actual es producto de sucesiones de parches, y no tiene un diseño fácil de entender o mejorar. Esto dificulta su evolución. La idea de crear un nuevo CVS desde cero, surgió en la propia compañía que ofrecía soporte comercial para el CVS.

 

Aumenta la funcionalidad:

  • Objetivo: mejorar y ampliar las prestaciones de CVS.
  • Registra cambios en la estructura de directorios (permite mover y renombrar sin perder el historial). Subversion no usa RCS, sino un sistema virtual de ficheros versionado sobre una base de datos. El uso de la base de datos Berkeley permite aislamiento, atomicidad, recuperación de datos, integridad, backups en caliente, y concurrencia sin necesidad de usar ficheros de lock. Con Berkeley DB no se pueden editar los ficheros a mano como con CVS, pero eso tampoco es necesario porque el repositorio no se corrompe. Subversion resulta más fiable que CVS sobre sistema de ficheros transaccional. Nota: Los logs de la base de datos llegan a ocupar bastante espacio, pero existe una herramienta para eliminarlos (svnadmin).
  • Commits atómicos, se realizan todos o ninguno. Las transacciones atómicas permite identificar conjuntos de cambios. Cuando un desarrollador sube un conjunto de ficheros lo hace en una transacción atómica, de modo que todos los ficheros se etiquetan con un número de revisión en el repositorio. La atomicidad también impide que el repositorio quede en estado no compilable porque la red cae durante la subida de cambios.
  • Servidor y cliente intercambian diferencias entre versiones. Al enviar una nueva versión nunca es necesario transmitir ficheros enteros.
  • Pueden añadirse propiedades arbitrarias (pares de clave y valor) a ficheros y directorios.
  • Interoperabilidad con WebDAV. Es posible acceder al repositorio con cualquier software que soporte dicho protocolo (“Web Folders” de Windows XP, Photoshop, etc.).
  • Apache + SSL puede usarse con firewalls y proxys.
  • MIME types y detección automática de ficheros binarios.
  • Permite operar directamente sobre el repositorio, sin copia local.
  • Permite backups en caliente.

 

Y mejora el rendimiento y diseño:

  • Protocolo WebDAV/DeltaV para el protocolo de red.
  • Arquitectura de red mejorada: Apache 2.0, envío de diffs binarios entre cliente y servidor, datos comprimidos con mod_deflate.
  • Se basa en APIs C bien definidas y documentadas. CVS en cambio, se construyo mediante sucesiones de parches.
  • Usa la biblioteca Apache Portable Runtime, que permite portar la capa de red a varios sistemas operativos.
  • El cliente es una pequeña aplicación que usa una biblioteca de alto nivel.
  • Versiona todos los ficheros guardando comprimidas sus diferencias.
  • No es necesario duplicar el código en el repositorio para crear ramas. Subversion usa copia perezosa, solo se crea un nuevo fichero cuando es modificado. Mientras tanto, el fichero de la nueva rama, esta implementado como un enlace al fichero original. En contraste, CVS tarda por ejemplo 40 minutos en crear un tag de release en el servidor de GCC. Es decir, en Subversion la operación es O(1), mientras que en CVS es O(n) (lineal respecto al tamaño del repositorio).
  • No es necesario conexión a red para ciertas operaciones: status, diff, revert. Esto se debe a que la copia local contiene una copia del fichero original presente en el repositorio. Este comportamiento ahorra ancho de banda a costa de mayor espacio en disco.

 

3. Como montar un servidor Subversion

Un servidor Subversion (SVN a partir de ahora) es un sistema de control de versiones. Para muchos una versión mejorada del CVS (Concurret Version System).

Orientado básicamente para desarroladores de software que trabajan en el mismo proyecto, pero desde distintas ubicaciones. Este software registra los cambios hechos en el código y quien ha sido el autor de dichas modificaciones. Así impide que si dos personas trabajan en la misma parte del código, los cambios que ha hecho una no sobrescriba las modificaciones hechas por la otra.

Por defecto este servidor escucha en el puerto 3690

Ahora a instalar dicho servidor.

Para Ubuntu : apt-get install subversion

Para Debian: aptitude install subversion

Para Centos : yum install subversion

Una vez instalado en nuestra maquina:

1. Creamos un usuario sin consola para que se encargue de ejecutar el svn (esto es por seguridad, es poco recomendable que root corra demonios). Nosotros le llamaremos svn

adduser svn -s /bin/nologin

2. Creamos un directorio que nos hará de repositorio. Lo crearemos en /opt/svn (lo puedes hacer en cualquier directorio.

mkdir /opt/svn

3. Ahora utilizaremos el comando svnadmin para indicarle al sistema que el directorio que acabamos de crear sera nuestro repositorio

svnadmin create /opt/svn

Si no ha habido ningún problema, veremos que dentro de /opt/subversion ha creado una estructura nueva de archivos y directorios (los directorios son conf, db, hooks y locks).

4. Ahora cambiamos el propietario a la carpeta /opt/svn por el usuario svn creado anteriormente:

chown -Rf svn:svn /opt/svn

5. Ahora configuraremos nuestro repositorio. Para ello entramos en la carpeta /opt/svn/conf. Allí encontraremos el archivo svnserve.conf. En el modificaremos unos valores para determinar los permisos que tendrán los usuarios y la forma de conectarse que tendrán. Aunque puede configurarse una conexión SSL, empezaremos por una conexión muy básica. Así que solo modificaremos estos 3 valores:

[general]

anon-access = none (quitar acceso a usuarios anónimos)

auth-access = write (permitir escribir a los usuarios autorizados)

password-db = passwd (donde definiremos los usuarios y sus contraseñas)

6. Ahora crearemos los usuario que tendrán acceso al repositorio. Lo haremos en el fichero passwd, ubicado en /opt/svn/conf

[users]

user1 = user1

user2 = user2

user3 = user3

Donde la primera columna es el nombre de usuario y la segunda la contraseña.

7. Ya tenemos configurado el servidor. Ahora solo resta arrancarlo. Para ello tenemos 2 opciones.

  • MANUALMENTE: En este punto, lanzaremos el demonio del SVN a mano utilizando el comando svnserve

svnserve -d -r /opt/svn

La opcion -d indica que el servidor correrá como demonio.

La opción -r indica que la raíz del repositorio sera /opt/svn.

  • AUTOMATICO (DAEMON): En este punto, lanzaremos el demonio del SVN automáticamente en cada arranque del sistema. Este servidor es lanzado por el demonio XINETD. Para que esto sea así, basta con crear un archivo llamado svn en la carpeta /etc/xinetd.d y asegurarse que este demonio (XINETD) arranque con el sistema. El archivo contendrá las siguientes lineas.

service svn

{

port = 3690

socket_type = stream

protocol = tcp

wait = no

user = svn

server = /usr/bin/svnserve

server_args = -i -r /opt/svn

}

Ahora bastara con arrancar el servicio XINETD y tendremos el demonio SVN escuchando.

Para comprobarlo, podemos con:

  • lsof -i |grep svn y nos tendrá que devolver la siguiente linea:

xinetd 2103 root 8u IPv4 5581 TCP *:svn (LISTEN)

Si queremos ver el log que va generando el servidor para detectar cualquier fallo:

tail -f /var/log/messages |grep svn

También se puede descargar la ultima versión desde la pagina web http://subversion.tigris.org/

 

4. Manejo de Usuarios en Subversion

Usuarios en subversion

Hay muchas formas de crear usuarios para subversion, incluyendo el que coja los de Windows. Sin embargo, una forma fácil de hacerlo es la siguiente.

Vamos al repositorio de PROYECTO1 recién creado y editamos el fichero conf/svnserve.conf. Por defecto viene con un montón de comentarios, pero en los que podemos leer claramente todas las opciones. Podemos dejar algo como esto

anon-access = read

auth-access = write

password-db = passwd

realm = PROYECTO1

Donde

  • anon-access = read indica permisos de lectura para usuario anónimos. Es decir, cualquiera podría sacar los fuentes para verlos, pero no podría subir los cambios.
  • auth-access = write indica permisos de lectura y escritura para usuarios autentificados.
  • password-db = passwd es el fichero donde estarán los nombres de usuario y passwords. En este caso, el fichero se llamará passwd y el path es relativo al fichero svnserve.conf que estamos editando.
  • realm = PROYECTO1 es el nombre que verán los usuarios cuando intenten acceder al repositorio y se les pida usuario y password. Puede ser cualquier palabra o frase que queramos. También se usará como clave para cifrado si corresponde.

Podemos dejar annon-acces = none para no dar ningún permiso a usuario anónimos.

Luego, editamos el fichero passwd que se crea por defecto (o el que hayamos indicado en password-db = passwd), lo editamos y ponemos los usuarios que queramos, de esta manera

[users]

chuidiang = la-password

federico = otra-password

juana = mas-passwords

Grupos en subversion

Si en el fichero svnserve.conf ponemos también una línea así

authz-db = authz

estamos indicando un fichero en el que podemos meter a los usuarios en grupos y en los que podemos dar permisos a cada grupo o usuarios a determinados directorios. Por ejemplo, suele ser una forma habitual de trabajo tener en el repositorio tres directorios: trunk, branches y tags.

  • trunk es la rama principal de desarrollo. Una forma de trabajo es que haya una persona responsable de esta rama y que garantice que es siempre estable. Esa persona puede ser la única con permisos de escritura en ella y recibir los cambios de los demás desarrolladores. Sólo el puede escribir, aunque todos los demás podrían leer.
  • branches y tags son para ramas secundarias y etiquetas. En la forma de trabajo anterior, los desarrolladores deben crearse su propia rama a partir de la principal y desarrollar en la rama. Cuando terminan, avisan al responsable de la rama principal para que prueba y lleve a ella los cambios realizados. Se puede dar permisos de escritura a este directorio branches a todos los desarrolladores.

El fichero authz puede contener cosas como esta

[groups]

administradores = chuidiang

desarrolladores = federico,juana

[/trunk]

@administradores = rw

@desarrolladores = r

* =

[/branches]

@administradores = rw

@desarrolladores = rw

* =

donde:

  • En [groups] se definen los grupos, poniendo nombre de grupo igual a los desarrolladores separados por comas.
  • Se ponen tantas secciones [/path] como se quiera y en ellas se pone
    • @nombre_grupo = permisos. Pueden ser rw, r o nada si no se quieren dar permisos
    • nombre_usuario = permisos.
    • * = permisos para el resto.

 

5. Comandos de Subversion

Comandos Básicos.

Una vez descargado localmente el proyecto en el que se va a trabajar, existen una serie de comandos para mantener actualizado tanto el proyecto en el repositorio como la copia local. Estos comandos son de la forma svn [comando] y teniendo que ejecutarse en el directorio o algún subdirectorio de la copia local. Los subcomandos [comando] son alguno de los siguientes:

  • update: Actualizar la copia local del proyecto con la versión más reciente del repositorio.
  • commit: Subir al repositorio los cambios realizados en la copia local. Además, hay que poner un mensaje de lo que se ha hecho en dichos cambios (con -m o mediante el editor que esté en la variable de entorno $SVN_EDITOR).
  • add: Con este comando se añade un nuevo archivo al repositorio. Hay que tener en cuenta que sólo se marca como añadido y hasta que no se haga el commit no se añade realmente.
  • checkout: Para descargar por primera vez una copia remota del proyecto a la máquina local.
  • revert: Restituye el archivo de copia de trabajo con los cambios de la última versión de la que se ha actualizado la copia local. Este comando no contacta con el servidor.
  • list: Lista los contenidos de un directorio dentro del repositorio.
  • status: Comprueba el estado de los archivos de la copia local con respecto a la última actualización de dicha copia. No realiza ninguna conexión con el repositorio.
  • info: Muestra información de algún directorio de algún proyecto del repositorio.
  • lock: Bloquea una ruta en el repositorio para que ningún usuario pueda hacer commit sobre dicha ruta.
  • unlock: Desbloquea rutas bloqueadas con lock.
  • blame: Imprime los cambios de un archivo respecto de versiones y quién los ha hecho.
  • merge: Une las diferencias entre dos copias de los archivos de trabajo que generalmente están en conflicto.
  • resolved: Indica que un conflicto ha sido resuelto.
  • log: Muestra los mensajes de log de la copia de trabajo. Es necesario hacer un update para que estén todos los logs del proyecto.
  • switch: Actualiza la copia de trabajo a un directorio distinto. Esto es útil para cambiar entre diferente branches que se verán en el siguiente punto.

 

BIBLIOGRAFIA:

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: