Control de versiones con Subversion

El proceso de instalación de Subversion en Windows es realmente sencillo.

¡Elige la distribución que contiene lo que necesitas (para este curso no usaremos Apache) y ya podemos empezar a trabajar!

Al estar Subversion incluido en la mayoría de repositorios de código la instalación de Subversion en los sistema Linux se reduce a una simple instrucción.

El repositorio y el working copy son los dos elementos principales y más visibles del Subversion. Antes de empezar a preparar nuestro primer proyecto veremos que son estos elementos y la motivación tras su arquitectura.

Nuestro primer paso consistirá en crear un repositorio centralizado donde se guardará la copia maestra compartida por todos los usuarios.

LLega el momento de crear nuestro primer repositorio.

Veremos como el comando svnadmin create nos permite esta creación y que aspecto tiene el repositorio recien creado.

El comando import nos permite incorporar un contenido inicial a nuestro repositorio. Debemos indicar en que lugar tenemos el primer contenido que voy ha proporcionar y, por supuesto, a que repositorio voy a realizar esta importación.

Veamos como la idea presentada en la lección anterior se traduce en código.

En está lección, en el material adicional, encontraréis el proyecto de prueba que utilizaremos en el ejercicio.

Ya tenemos un repositorio con una primera versión del proyecto. Para seguir trabajando necesitaremos crear un working copy en nuestro espacio local y lo haremos mediante el comando svn checkout (o svn co)

Nuestro trabajo en un working copy se inicia con la creación de éste. El comando svn checkout permite crear un working copy para un repositorio concreto.

¡Ya hemos visto todos los pasos para empezar el trabajo!

¿Qué os parece si paramos un poco y repasamos uno por uno lo que hemos hecho?

Como con la mayoría de herramientas, se cumple el principio del 10 / 90: ¡El 10 por ciento de los comandos de Subversion se usan el 90% del tiempo!

En esta y la siguiente lección vamos a ver en acción cuales son estos comandos más usados.

Seguimos con la exposición de los comandos de uso más habitual en Subversion. En esta sección se explican el comando status, add, del, revert y commit.

En las lecciones anteriores, a aparecido algunas veces el concepto de revision. En esta lección explicaremos de forma detallada en que consiste este concepto importantísimo en el uso de Subversion.

Una característica fundamental de Subversion es el "recuerdo" que tiene de todo el historial por el que ha pasado nuestro proyecto. svn move es un comando que ayuda a Subversion en esta tarea cuando renombramos o cambiamos la ubicación de un fichero o directorio.

¡Que sería de los programas sin su sistema de ayuda!

En esta lección se proporcionan las principales ideas para sacar provecho a esta herramienta.

Hemos visto como iniciar un proyecto usando el comando import.

En esta lección veremos como empezar de otra forma un proyecto con los comandos que ya han sido presentados.

Por supuesto, numerosas herramientas ofrecen integración con Subversion.

En esta lección veremos una de estas herramientas, Eclipse, y de que forma da acceso a los comandos que ya conocemos.

Los repositorios en el mismo ordenador son la mejor manera de introducirse a la herramienta y probar de forma ágil todo lo que vamos aprendiendo.

Pero seguramente muchos de vosotros estais impacientes por probar un sistema más "real", con un servidor externo y un acceso seguro. Para vosotros está esta clase: Vamos a crear un proyecto utilizando el servidor de subversion proporcionado por el servicio SourceForge

El objetivo de este curso es obtener un conocimiento sólido y profundo de Subversion.

En esta lección se presentan los motivos por los que este objetivo es más viable trabajando directamente sobre la herramienta en lugar de utilizar otros recursos como Eclipse o repositorios externos.

Seguimos con comandos destinados a interrogar sobre el pasado y presente de nuestro proyecto. En este caso, ampliamos nuestro repertorio con comandos que interrogan directamente sobre el contenido del repositorio.

Ya conocemos que es el working copy y como lo usamos en nuestro trabajo diario.

En esta lección vamos a ir más allá (de hecho, mucho más allá!) y veremos como estructura internamente su información para poder dar los servicios que aporta.

Supongamos que teneis que enviar una copia del proyecto al cliente. El cliente no va a trabajar con Subversion en el proyecto: solo lo va a usar.

¿Cual es el inconveniente de enviarle el resultado de un checkout? ¿Como podemos mejorarlo? En esta lección presentaremos el comando que lo permite: svn export.

A partir de subversion 1.6 se añadió el uso del carácter caret (^) para facilitar la expresión de URLs cuando nos referíamos a un repositorio desde un working copy asociado.

En esta lección introduciremos esta notación.

Y una observación importante: ¡Si usáis Windows, no paséis por alto el documento descargable en la sección de material adicional!

Los change list permiten mantener conjuntos de ficheros separados y aplicar sobre ellos los comandos ya vistos.

Este recurso nos ayuda a organizarnos cuando realizamos distintas tareas simultáneamente sobre el mismo working copy.

No todos los elementos de nuestro working copy se encuentran siempre sincronizados con la misma revisión del repositorio. Este estado se conoce como mixed revision.

En este estado, algunos comandos pueden ofrecer un comportamiento extraño o, incluso, fallar completamente.

En esta lección veremos como se produce, detecta y finalmente, soluciona, la situación de mixed revision.

En esta lección aprenderemos a asociar propiedades a ficheros o directorios contenidos en el Subversion.

En esta lección seguimos con las propiedades pero ahora nos centramos en la non-versioned: Propiedades que son asociadas a una revisión.

En esta lección conoceremos la existencia de un tipo especial de propiedades que son reconocidas por Subversion. Profundizaremos en una de las más usadas: svn:ignore.

En esta lección aprenderemos a reutilizar el contenido de una carpeta del repositorio entre distintos proyectos

Algunas operaciones, por defecto, se propagan por los subdirectorios a partir del lugar donde son aplicadas. Otras, por el contrario, solo se aplican directamente sobre el path especificado. La recursividad es el concepto que se refiere a estos diferentes comportamientos.

En esta lección veremos como controlar la recursividad con la que actuan distintos comandos del Subversion.

En esta lección aprenderemos como usar la opción depth para controlar que partes del repositorio queremos excluir de nuestro working copy

Para facilitarnos el trabajo, Subversion define una serie de palabras claves para referirnos a revisiones destacadas del proyecto.

En esta leccion veremos en detalle cuales son y a que revisiones se refieren.

¡Apréndelo bién! Estas palabras claves proporcionan un toque de elegancia que seguro que será admirado por tus compañeros ;-)

A estas alturas ya está claro la importancia del concepto de revisión en Subversion.

En esta lección ampliaremos nuestro arsenal de recursos con otra forma de referirnos a las revisiones. Pero no os penseis que esta lección va de "hacer lo mismo pero de forma diferente"!. Veremos como el uso de las peg revisions nos permiten realizar operaciones que, con los recursos que teniamos hasta ahora, no serían posibles.

Seguro que muchos llevais tiempo esperando tratar la cuestión: ¿Que sucede cuando dos usuarios modifican el mismo fichero?

En esta lección empezamos el tratamiento de este tema, la concurrencia. Y lo hacemos explicando el modelo básico que tiene Subversion para detectar y evitar (no sin inconvenientes) este tipo de situaciones.

El modelo de concurrencia explicado en la lección anterior no sirve para todos o para todas las situaciones.

En esta lección explicaremos como podemos introducir bloqueos que nos permitan un acceso exclusivo a las modificaciones de un fichero.

Tratamos en esta lección una de las posibles situaciones cuando se producen modificaciones concurrentes en un fichero: el merge.

En este caso, el más favorable, Subversion consigue combinar las dos fuentes de cambios sobre el mismo fichero.

Esta lección se situa en una situación pero que la anterior: en este caso, Subversion no consigue combinar las dos fuentes de cambios y se produce una situación de conflicto.

Veremos como se produce y que recursos tengo para solucionarlo.

La tercera situación posible es la de tree conflict. Esta situación se produce alguno de los cambios (o los dos) incluye cambios estructurales.

Esta lección muestra un ejemplo de esta situación y algunas ideas de como resolverlo.

Esta lección responde a la pregunta ¿Por que me interesa tener distintas versiones de mi proyecto?

¡Para entender correctamente como funcionan las ramas, hay que empezar por conocer bién su razón de ser!

Vista la necesidad de tener distintas versiones en la lección anterior, ahora es el momento de ver como organizarlas.

Mostraremos en detalle cual es el convenio establecido en Subversion y usado en la mayoría de proyectos

El trabajo con ramas requiere de acciones realizadas directamente sobre el repositorio.

En esta lección veremos como podemos realizar estas acciones mediante los comandos que ya conocemos, pero aplicados de forma diferente.

Ya sabemos que son las versiones, como organizarlas y que comandos me permiten hacerlo.

¡Llega el momento de ver este proceso en acción!

Tener distintas versiones de mi proyecto no implica tener que duplicar todo el trabajo.

En esta lección veremos como propagar los cambios realizados en una versión a otra diferente, mediante el comando merge.

Ahora que disponemos de distintas versiones del producto, llegará el momento en el que me interesará pasar de trabajar de una version a otra.

El comando svn switch permite cambiar con que ubicación del repositorio trabaja un working copy. Es especialmente útil cuando queremos que un working copy pase de trabajar con una versión (por ejemplo trunk) a otra (por ejemplo la rama actual de producción).