Subversion

Este documento se publica bajo la licencia "Creative Commons Attribution License". Para ver una copia de la licencia visita http://creativecommons.org/licenses/by/1.0/ o envía una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

22 marzo 2004

Historial de revisiones
Revisión 122 marzo 2004
Revisión 224 julio 2004
Revisión 331 julio 2004

Tabla de contenidos

Introducción
Sistemas de control de versiones
¿Por qué son necesarios?
¿Por qué SVN?
Aprender Subversion desde CVS
Instalación
Instalar Subversion
Crear un repositorio
Acceso remoto con Apache
Acceso remoto con svnserve
Importar un proyecto
Uso
Como puedo ...?
Propiedades
Lo mínimo que necesita saber un cliente
Software relacionado
GUIs
Bibliotecas
Plugins
Scripts
Otros
Enlaces
Subversion para no desarrolladores
¿Qué es?
¿Como funciona?
¿Qué requiere?
Un ejemplo de sesión de trabajo

Introducción

Este artículo es un tutorial del sistema de control de versiones Subversion. Se incluyen ejemplos para Windows y *nix. No se asumen conocimientos previos. Visita 1x4x9.info para obtener la última versión.

La referencia definitiva sobre Subversion es el libro electrónico "Version Control with Subversion", que se distribuye gratis en Internet, y que publica O'Reilly en digital y papel. Dicho libro contiene toda la información necesaria para instalar, usar, administrar, y desarrollar Subversion. Este documento solo cubre una mínima parte de su contenido.

Sistemas de control de versiones

Un sistema de control de versiones es un software que administra el acceso a un conjunto de ficheros, y mantiene un historial de cambios realizados. El control de versiones es útil para guardar cualquier documento que cambie con frecuencia, como una novela, o el código fuente de un programa.

Normalmente consiste en una copia maestra en un repositorio central, y un programa cliente con el que cada usuario sincroniza su copia local. Esto permite compartir los cambios sobre un mismo conjunto de ficheros. Además, el repositorio guarda registro de los cambios realizados por cada usuario, y permite volver a un estado anterior en caso de necesidad.

Pero, ¿que hacer cuando dos usuarios intentan modificar el mismo fichero?. Existen dos estrategias:

  • Bloqueos: el usuario bloquea el fichero durante su edición, evitando el acceso concurrente de otros usuarios. Existen varios problemas: el usuario que acapara ficheros, el interbloqueo entre usuarios que necesitan varios ficheros, y la falta de concurrencia.

  • Merge (fusión de cambios): los ficheros se acceden concurrentemente. Los cambios realizados sobre un mismo fichero son fusionados inteligentemente por el sistema. El único problema es el intento de fusión de cambios incompatibles, que ha de solucionarse manualmente.

Existen multitud de sistemas de control de versiones, pero sin duda, el más popular es CVS (Concurrent Versions System). CVS tuvo el merito de ser el primer sistema usado por el movimiento de código abierto para que los programadores colaboraran remotamente mediante el envío de parches. Es de uso gratuito, código abierto, y emplea fusión de cambios.

Subversion se creó para igualar y mejorar la funcionalidad de CVS, preservando su filosofía de desarrollo. Su desarrollo comenzó en el año 2000 como proyecto de código abierto esponsorizado por CollabNet. El líder del equipo de desarrollo fue Karl Fogel, autor de Open Source Development with CVS, y fundador de Cyclic Software (compañía de desarrollo y soporte comercial para CVS, hoy adquirida por SourceGear). La versión 1.0 fue publicada en febrero del 2004. Emplea licencia Apache/BSD.

Hay una comparativa entre 13 sistemas de control de versiones en better-scm.berlios.de, y otra entre Subversion y CVS en wiki.gnuarch.org. Este último web es también el wiki de GNU Arch, un sistema de control de versiones de código abierto que no he probado.

¿Por qué son necesarios?

Supongamos que estamos haciendo un programa de cierto tamaño en colaboración con otra persona. Lo más primitivo es compartir cambios usando ficheros comprimidos. Pero este sistema es propenso a errores: ¿estamos enviando todo el código?, ¿estamos sobrescribiendo algún cambio?, ¿que ficheros debemos actualizar?, ¿quien tiene la versión maestra del código?

Todos los sistemas de control de versiones tienen ciertas características que acaban con estas preocupaciones. Esto es lo que aporta un sistema de control de versiones a un equipo:

  • Actualiza ficheros modificados. El cliente recorre nuestro código y sincroniza nuestra copia local con el repositorio.

  • Copias de seguridad centralizadas. Solo el administrador debe preocuparse de realizar copias de seguridad en el repositorio. Esto se automatiza fácilmente con una tarea cron o similares.

  • Historial de cambios. El repositorio guarda registro de todos los cambios realizados. Es posible recuperar cualquiera de las versiones anteriores de cualquier fichero. Si alguien borra todos los ficheros, podemos volver atrás y recuperar su contenido.

  • Acceso remoto. Es posible acceder remotamente al repositorio. No es necesario que el equipo este dentro de la misma LAN.

  • Seguridad. Es posible otorgar diferentes permisos sobre diferentes ramas del proyecto. Por ejemplo, estableciendo permiso universal de lectura, y permiso de escritura solo a ciertos usuarios.

Desarrollar un proyecto de software implica invertir mucho tiempo y dinero. No proteger nuestra inversión con un sistema de control de versiones es irresponsable y denota un grave desconocimiento del desarrollo de software.

¿Por qué SVN?

Si eres desarrollador seguramente conocerás CVS. Se emplea en la mayoría de proyectos comerciales, y prácticamente en todos los de código abierto. Pero últimamente se habla de un sustituto de CVS. La fundación Apache por ejemplo, ya permite que sus proyectos migren a Subversion si lo desean. Esta sección se explica porque es necesario el cambio.

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.

Aprender Subversion desde CVS

La filosofía de trabajo es la misma entre los dos sistemas, los comandos básicos (checkout, add, commit, update, etc.) también. Pero algunas cosas han cambiado (a mejor):

  • Subversion proporciona comandos con nuevas funcionalidades: copy, move, merge, resolve, mkdir, propset, propget, proplist, propdel, propedit, revert, switch, info.

  • Numeración de versiones. Con Subversion los números de versión son globales para todo el repositorio. No hay un número de versión por fichero.

  • Autentificación:

    • CVS usa un modo de autentificación propio, con un protocolo propio. Este protocolo debe usarse con SSH tunneling, o implementaciones CVS de kerberos o GSS para que sea seguro.

    • Subversion se usa normalmente con HTTP + autentificación BASIC o SSL. También incluye un servidor propio que podemos usar con SSH tunneling.

  • Dejan de existir los conceptos de módulo, ramas, y etiquetas, como entidades separadas:

    • Ramas y etiquetas (branches y tags): Internamente no existen tales conceptos, si quieres una rama la creas a partir de un enlace a un número de revisión del código (se comparte el historial, no es necesario copiar el proyecto entero). Una etiqueta es una rama a la que no se le añaden más cambios.

    • Módulos: En Subversion solo existen directorios, no hay concepto de módulo.

  • Palabras clave. Las palabras clave de CVS se expanden automáticamente. Esto fuerza al usuario a desactivar este comportamiento explícitamente, corriendo peligro de destruir ficheros binarios. En Subversion, este comportamiento debe ser activado explícitamente.

  • En Subversion existen varios protocolos de acceso: HTTP, SVN, file:///.

Si ya conoces CVS, cambiar a Subversion es sencillo.