Introduccion a Subversion

Alejandro Alvarez
Ayllon
21 de febrero de 2008
Este apendice es una gua introductoria al sistema de control de versiones
Subversion. Si necesita una documentacion completa puede consultar Version
Control with Subversion[4]

1.

Introducci
on

1.1.

Qu
e es

Subversion es un sistema libre de control de versiones, es decir, controla los

archivos y directorios y sus cambios a lo largo del tiempo.
Un
arbol de archivos se almacena en un repositorio central, que es como un
sistema de archivos normal, con la diferencia de que almacena todos los cambios
realizados.
Permite acceder a traves de la red, por lo que puede ser usado desde distintos
ordenadores, incentivando la colaboracion, ya que se trabaja sobre el mismo
conjunto de datos.
Dado que los cambios no se centralizan, se progresa mas rapidamente, sin
perder adem
as calidad en el proceso, ya que si se realiza un cambio erroneo
puede deshacerse.
Adem
as, puede controlar desde codigo fuente en cualquier lenguaje hasta
ediciones de vdeo.

1.2.

Vocabulario

A continuaci
on se describen algunos terminos de uso habitual en este ambito.
Lnea base (Baseline) Una revision aprobada a partir de la que se pueden
realizar cambios.
Rama (branch) Conjunto de ficheros con dos o mas copias mantenidas de
forma independiente.
Check-out (checkout, co) Crear una copia para trabajar localmente.

Commit (check-in, ci, install, submit) Escribir los cambios

locales sobre el repositorio.
Conflicto Ocurre cuando se realizan cambios por diferentes partes al mismo
documento, y el sistema es incapaz de reconciliar los mismos.
Cambio (change, diff, delta) Representa una modificacion de un documento.
Lista de cambios (changelist, change set, patch) Conjunto de cambios realizados en un u
nico commit.
Exportaci
on (export) Una exportacion es similar a un check-out, salvo
porque crea un
arbol de directorios limpio sin los metadatos de control de
versiones presentes en la copia de trabajo.
Importaci
on (import) Es la accion de copia un arbol de directorios local
en el repositorio por primera vez.
Integraci
on (merge) Una integracion une dos conjuntos de cambios sobre
un fichero o un conjunto de ficheros en una revision unificada de dicho
fichero.
Puede suceder cuando un usuario actualiza su copia local con los cambios
realizados por otros usuarios. Analogamente, este mismo proceso puede
ocurrir en el repositorio cuando un usuario intenta subir sus cambios.
O despues de que se haya creado una rama y sea necesario aplicar en ella
un cambio realizado en otra (solucionar un error anterior a la division, por
ejemplo)
O cuando se quieran fundir dos ramas diferentes de desarrollo.
Repositorio El repositorio es el lugar en el que se almacenan los datos actualizados e hist
oricos
Integraci
on inversa El proceso de fundir ramas de diferentes equipos en la
rama principal del sistema de versiones.
Revisi
on (versi
on) Una revision es una version dentro de una cadena de
cambios.
Etiqueta (tag, release) Se puede etiquetar un conjunto de ficheros con
un nombre f
acil de identificar, o con un n
umero de revision.
Resolver Intervenci
on del usuario para atender un conflicto entre diferentes
cambios al mismo documento.
Actualizaci
on (sync) Integracion de los cambios que han sido hechos en
el repositorio sobre la copia de trabajo local.
Copia de trabajo Copia local de los ficheros de un repositorio. Todo el trabajo
realizado sobre los ficheros en un repositorio se realiza inicialmente sobre
una copia de trabajo.
2

1.2.1.

Caractersticas

Control de directorios Subversion implementa un sistema de ficheros virtual que controla los cambios a todo el arbol de directorios.
Control verdadero Subversion permite el a
nadido, borrado, copia y renombrado de archivos y directorios, teniendo cada nuevo archivo un historial propio aunque el nombre coincida con un archivo antiguo que fuera
borrado.
Envos at
omicos Un conjunto de cambios se aplican al repositorio completamente o no se aplica ninguno, evitando inconsistencias.
Metadatos versionados A cada archivo o directorio se le puede aplicar cualquier propiedad que se quiera, manteniendo un historial de los cambios.
Elecci
on de las capas de red Subversion abstrae el acceso al repositorio, por
lo que se puede implementar distintas maneras de hacerlo a traves de la
red: como m
odulo de Apache HTTP Server, por ejemplo. Tambien existe
un peque
no y ligero servidor que puede usarse facilmente a traves de SSH.
Manejo consistente de los datos La diferencia entre archivos se almacena
usando un algoritmo diferencial binario, por lo que se puede aplicar a
archivos de texto o binarios.

2.

Instalaci
on

Subversion est
a construido sobre una capa de portabilidad llamada APR
(Apache Portable Runtime library), lo que significa que es capaz de funcionar
en cualquier sistema operativo en el que el servidor Apache httpd se ejecute:
Windows, Linux, todos los BSD, Mac OS X, Netware, etc.
La manera m
as sencilla de instalarlo es descargar el paquete construido para
su sistema operativo desde el sitio web de Subversion (http://subversion.tigris.org).
Normalmente pueden encontrarse instaladores graficos para los usuarios de sistemas operativos de Microsoft. Si usa un sistema Unix-like, puede usar el sistema
nativo de paquetes (RPMs, DEBs, etc.) para obtener Subversion.
Como alternativa, puede compilar Subversion directamente a partir de la
u
ltima versi
on del c
odigo fuente. Antes de descomprimirlo siga las instrucciones del archivo INSTALL. Tenga en cuenta que un paquete contiene todo lo
necesario para compilar un cliente capaz de conectarse a repositorios remotos,
pero opciones adicionales pueden tener otras dependencias (como Berkeley DB
o Apache httpd). Si quiere compilar una version completa debe asegurarse de
que tiene todos los paquetes listados en el archivo INSTALL.
Si quiere trabajar en el codigo, puede usar su cliente para obtener el codigo
m
as reciente.

3.

Gua b
asica r
apida

Lo primero que debe tener en cuenta es el comando que le resultara mas u

til
para empezar a usar Subversion: svn help. Puede usarlo de la forma svn help
COMANDO para obtener ayuda sobre el comando pasado como parametro.

3.1.

Checkout inicial

Lo primero que debe hacer es obtener una copia de trabajo local a partir del
repositorio central:
$ svn checkout svn://osl.uca.es/proyecto
Esto crear
a un nuevo directorio llamado proyecto, dentro del que se descargar
an todos los archivos del mismo. Una vez hecho esto ya puede empezar a
trabajar como lo hara normalmente.
NOTA: Aunque puede usarlo como si fuera un directorio normal,
para copiar o mover archivos debera usar los comandos svn copy y
svn move en lugar de los habituales.
Dentro de cada directorio del proyecto se creara otro directorio llamado
.svn. No borre ni modifique su contenido bajo ning
un concepto.
Si quiere descargar el proyecto en un directorio con un nombre diferente,
puede hacerlo:
$ svn checkout svn://osl.uca.es/proyecto MiProyecto
De esta forma en lugar de crear un directorio llamado proyecto se creara uno
llamado MiProyecto.

3.2.

Ciclo de trabajo b
asico

Pese a la gran variedad de comandos que tiene Subversion, la mayora de las

veces bastan unos pocos de ellos. El ciclo normal es:
3.2.1.

Actualizar la copia de trabajo

Cuando quiere actualizar su copia de trabajo con el repositorio central debe

ejecutar svn update.
$ svn update
U INSTALL
U README
Cuando se ejecuta esta orden se muestra una lista de los archivos actualizados
junto con una letra que indica el tipo de cambio:

U El archivo se ha actualizado.
A El archivo se ha a
nadido.
D El archivo ha sido borrado.
R Se ha sustituido el archivo por otro con el mismo nombre. Subversion los
considera diferentes.
G El archivo actualizado haba sido modificado localmente, pero los cambios
no se pisan, as que se han fundido ambas versiones.
C Los cambios locales y los realizados en el repositorio se solapan. Es necesario
solucionar manualmente el conflicto.
3.2.2.

Realizar cambios

Hay dos tipos de cambios:

Cambios en un archivo. Editarlo normalmente con el programa adecuado:
editor de texto, de gr
aficos, etc. Subversion detecta automaticamente los
cambios.
Cambios en el
arbol de directorio. Pueden a
nadirse archivos o directorios, borrarlos, moverlos, copiarlos, etc. Para estos cambios debe usar los
comandos de Subversion. Se realizan localmente en el acto, y en el repositorio cuando se enven los cambios.
Los comandos son:
svn add A A
nade el archivo (o directorio) A (y todo su contenido).
svn delete A Elimina el archivo (o directorio) A (y todo su contenido).
svn copy A B Duplica el archivo (o directorio) A con el nombre B y lo a
nade
al repositorio.
svn move A B Equivalente a svn copy A B; svn delete A
svn mkdir A Crea un nuevo directorio A.

3.3.

Revisar los cambios

Los siguientes comandos pueden emplearse sin necesidad de una conexion al

repositorio central.
svn status Informa sobre todos los cambios realizados a archivos o al arbol de
directorios. Delante de cada nombre de archivo aparecen tres columnas. La
primera se refiere al estado del archivo, la segunda al de sus propiedades y
la tercera muestra una L cuando esta bloqueado (locked ), posiblemente por
un commit en curso. Los valores que pueden aparecer en las dos primeras
columnas son:
5

A Ha sido a
nadido.
C En conflicto.
D Marcado para borrar.
M Modificado.
R Marcado para ser reemplazado.
X No est
a versionado pero esta relacionado con definiciones externas (para m
as informaci
on consultar el manual de Subversion).
? No est
a bajo control.
! Est
a bajo control pero no se encuentra o tiene alg
un error. Puede usar
svn revert para recuperarlo.
Est
a bajo control como un tipo diferente al que hay en la copia de
trabajo (por ejemplo, controlado como archivo y actualmente es un
directorio).
I No est
a bajo control y esta marcado para que subversion lo ignore cuando se usen los comandos svn add, svn status y svn import.
svn diff Muestra los cambios realizados sobre un archivo en concreto si se especifica o sobre todos en general. Indica las lneas a
nadidas y eliminadas
usando el formato del diff unificado[2].
svn revert Deshace los cambios realizados sobre el fichero o directorio pasado
como par
ametro, volviendo a la revision anterior.

3.4.

Solucionar conflictos

Si Subversion encuentra un conflicto al actualizar un fichero creara tres archivos que no est
an bajo control del repositorio:
filename.mine El archivo de la copia de trabajo.
filename.rOLDREV La revision anterior (sin cambios).
filename.rNEWVER La nueva revision obtenida del repositorio central al
actualizar.
Subversion no le permitira subir cambios hasta que estos tres archivos hayan
sido borrados.
Puede solucionarlo de tres maneras:
Manualmente Editando el archivo de la copia de trabajo y ejecutando svn
resolved FILENAME.
Sobreescribiendo el archivo Puede sobreescribir el archivo local1 con uno
de los anteriores y ejecutando tambien svn resolved FILENAME.
1 mv

filename.rNEWVER filename

Usando svn revert Deshace los cambios que ha realizado para que pueda
volver a editar el archivo. No es necesario ejecutar svn resolved FILENAME.

3.5.

Enviar los cambios

Una vez haya realizado todos los cambios pertinentes, puede subirlos usando
svn commit. Es necesario suministrar un mensaje para el historial. Puede
hacerlo como par
ametro:
$ svn commit --message "Nuevas modificaciones"
O tomando el mensage del contenido de un archivo:
$ svn commit --file logmsg
Y, en el caso de que no se especifique, se ejecutara el editor configurado por
defecto2 para que pueda escribir el mensaje. Puede ignorarlo y no guardar el
archivo (en cuyo caso se le preguntara si desea continuar) o dejarlo vaco.

4.

Examinar el historial

Los comandos para recuperar informacion sobre el historial del repositorio

o de un archivo en concreto son:
svn log Muestra el historial de quien realizo los cambios, cuando y el mensaje
enviado. Par
ametros:
svn log revision 5:19 Muestra el historial entre las revisiones 5 y 19 en orden cronol
ogico.
svn log -r 19:5 Muestra el historial entre las revisiones 5 y 19 en orden inverso.
svn log -r 8 Muestra el historial del cambio 8.
El par
ametro -v indica que muestre tambien los archivos modificados, eliminados o a
nadidos.
Tambien se le puede pasar un archivo como parametro para mostrar solo su
historial: svn log README
svn diff Como ya se ha dicho, muestra las diferencias entre dos revisiones de
uno o varios archivos. Sin parametros lo muestra entre la copia de trabajo y la
u
ltima revisi
on, aunque puede compararse con una anterior:
$ svn diff --revision 3 README
O dos revisiones entre ellas:
$ svn diff --revision 2:3 README
2 A trav
es de la variable del sistema EDITOR o a trav
es del fichero de configuraci
on de
Subversion (.subversion/config)

svn cat
creto:

Permite mostrar el contenido de un archivo en una revision en con-

$ svn cat --revision 3 README

svn list

Muestra el contenido de un directorio del repositorio.

Recuperar una revisi

on anterior Pueden emplearse los comandos svn update y svn checkout para obtener una revision antigua:
$ svn checkout --revision 50

5.

Otros comandos

svn cleanup Si por alg

un error un commit falla, este comando enva el mensaje de historial si no se llego a hacer y/o desbloquea los archivos y directorios
bloqueados.
svn import Copia un
arbol de directorios sin control a un repositorio. El
directorio original queda como esta, as que para poder trabajar sobre una copia
versionada es necesario hacer un checkout.
$ svn import directorio svn://osl.uca.es/proyecto
Resulta u
til para enviar a un repositorio recien creado todos los archivos de
un proyecto que ya exista para poder mantenerlo versionado.

6.
6.1.

Ramas
Qu
e es una rama?

Supongamos que tenemos un documento del que nos piden una copia con
algunas diferencias del original. Obviamente lo que se hace es crear una copia
sobre la que realizar los cambios, conservando el original. Se trabaja sobre ambos
archivos, modificando a veces uno, a veces otro.
Ahora imaginemos que hay un error en el archivo que es anterior a esta
divisi
on, por lo que posiblemente esta en ambas copias, que son practicamente
iguales, por lo que hay que realizar el mismo cambio en las dos.
Esta es la idea de una rama: archivos mantenidos de forma independiente
pero que comparten un pasado com
un. Una rama siempre empieza como una
copia de algo, pero teniendo su propio historial desde entonces.

6.2.

Trabajando con las ramas

En este apartado se describe de una manera muy superficial el trabajo con

ramas en un repositorio.
8

6.2.1.

Crear una nueva rama

Es tan f
acil como crear una copia.
$ svn copy trunk branches/mi_rama
Los datos no se duplican en el repositorio, as que no hace falta preocuparse por
un incremento de tama
no.
Nota: Por convenci
on suelen crearse bajo el directorio branches, pero puede
usarse cualquier otro: ramas, estable, etcetera.
6.2.2.

Trabajar con la rama

Puede hacerlo de forma normal, como un directorio mas del proyecto, aunque
es posible (como con todos los subdirectorios de un proyecto) de obtenerlo por
separado:
$ svn checkout svn://osl.uca.es/proyecto/branches/mi_rama
6.2.3.

Copiar cambios entre ramas

Mientras que se trabaje con copias distintas no hay problema de que los
cambios se pisen, pero hay que tener en cuenta que conforme mas tiempo se
trabaje por separado, m
as difcil puede ser unir los cambios con el tronco del
proyecto sin que surjan multitud de conflictos.
Para aplicar los cambios realizados en la rama principal sobre la copia en las
que estamos trabajando se emplea el comando svn merge, muy similar a svn
diff, con la diferencia de que aplica los cambios en la copia de trabajo en lugar
de mostrar los cambios por consola, marcando el archivo como modificado.
$ svn merge svn://osl.uca.es/proyecto/trunk
Puede especificarse el directorio sobre el que aplicar los cambios.
$ svn merge svn://osl.uca.es/proyecto/trunk mi_rama
Una vez hecho esto puede actualizarse el repositorio indicando que se ha
aplicado una modificaci
on sacada de la rama principal.
$ svn commit --message "Importado los cambios desde trunk"
Para consejos sobre como usar estas funciones, consulte el captulo 4 de [4].
6.2.4.

Mantenimiento de ramas

Directorios Se recomienda mantener una estructura de directorios estandar

que facilite el trabajo con ramas. Si el repositorio solo contiene un proyecto:
/trunk

/branches
/tags
Si contiene m
as se replica la estructura anterior:
/proyecto1/trunk
/proyecto1/branches
/proyecto1/tags
/proyecto2/trunk
/proyecto2/branches
/proyecto2/tags
En cualquier caso no es obligatorio, puede elegir la distribucion que mas le
guste.
Vida de los datos Una vez ha finalizado el trabajo en una rama y se han
integrado los datos en la rama principal, puede borrarse usando svn delete.
Otra utilidad de las ramas es cuando se quiere liberar una version estable,
por lo que hay que trabajar en solucionar bugs, pero sin dejar de a
nadir nuevas
funciones:
$ svn copy svn://osl.uca.es/proyecto/trunk
svn://osl.uca.es/proyecto/branches/estable-1.0
De esta forma se pueden seguir a
nadiendo caractersticas en /trunk y trabajar s
olo en solucionar errores en /branches/estable-1.0

7.

Administraci
on

Los detalles sobre la administracion se explicaran solo de forma superficial.

Si quiere m
as informaci
on: Version Control with Subversion[4]

7.1.

Utilidades

svnlook Se emplea para examinar revisiones y transacciones. Es de solo lectura,

no modifica el repositorio. Sus funciones se salen del caracter introductorio
de este apendice. Para mas informacion puede ejecutar svnlook help.
svnadmin Permite ejecutar operaciones de mantenimiento. Los parametros
que acepta son:
create Crea un nuevo repositorio: svnadmin create proyecto.

10

deltify Comprime el repositorio almacenando solo las diferencias respecto

a la versi
on anterior.
dump Vuelca el contenido del repositorio empleando un formato portable.
hotcopy Crea una copia de un repositorio de forma segura, aunque este siendo usado.
list-dblogs Muestra los archivos de historial de Berkeley DB asociados
con el repositorio.
list-unused-dblogs Muestra los archivos de historial de Berkeley DB
asociados con el repositorio y que ya no son usados. Pueden borrarse
sin problemas, aunque podran almacenarse para recuperarse de una
perdida de datos catastrofica.
load Carga una serie de revisiones en un repositorio a partir de un flujo
de datos que emplee el mismo formato de volcado que el subcomando
dump.
lstxns Muestra la lista de transacciones que todava no han sido enviadas.
recover Realiza una recuperacion en caso de error.
rmtxns Elimina las transacciones limpiamente.
setlog Sustituye el mensaje de historial de una revision en concreto por
otro nuevo.
verify Comprueba la integridad del repositorio.

7.2.

Restaurar un repositorio

Pr
acticamente cualquier error - corrupcion de datos, cambios no deseados,...
- puede solucionarse empleando el comando svnadmin recover REPOSITORIO. Antes de ejecutarlo debe asegurase de que:
1. No haya ning
un proceso accediendo al repositorio.
2. Es el usuario propietario del repositorio. No solo como root, ya que es
posible que se generen de nuevo algunos archivos, y si se crean como root
no ser
an despues accesibles.

7.3.

Crear una copia de seguridad

Pueden realizarse de dos maneras: una copia completa o incremental.

Una copia completa es basicamente una duplicacion del repositorio. Ahora
bien, a menos que deshabilite los accesos al repositorio puede obtener una copia
inconsistente si se est
an realizando cambios mientras realiza la copia, as que lo
correcto es usar svnadmin hotcopy o bien un script suministrado por Subversion: hot-backup.py - puede encontrarlo en tools/backup dentro del directorio
de instalaci
on de Subversion.
Para obtener una copia incremental puede usar svnadmin dump incremental:
11

$ svnadmin dump repositorio 0:100 > dump01

$ svnadmin dump 101:200 > dump02
$ svnadmin dump 201:300 > dump03

8.

Configuraci
on del servidor

Aunque Subversion permite usar, gracias a su capa de abstraccion, cualquier

protocolo de red, en realidad actualmente solo existen dos servidores: Apache
con el m
odulo mod dav svn o svnserve, un peque
no servidor independiente.

8.1.

svnserve

Este servidor puede lanzarse de tres formas diferentes.

inetd
$ svnserve -i
De esta forma svnserve se comunica con svn a traves de la entrada y salida
est
andar.
Si su sistema utiliza un demonio inetd, puede editar el archivo /etc/inetd.conf
y a
nadirle la siguiente lnea:
svn stream tcp nowait USUARIO /usr/bin/svnserve svnserve -i
Donde USUARIO es el usuario que tiene permisos para acceder al repositorio.
Demonio
$ svnserve -d
De esta forma escuchar
a en el puerto 3690, aunque puede cambiarlo usando
el par
ametro listen-port=.
T
unel
$ svnserve -t
De esta forma presupone que un programa como RSH o SSH ha autentificado
al usuario y que se ha invocado un servicio svnserve.
Cuando se ejecuta el servidor de esa forma, el cliente debe especificar la ruta
absoluta del repositorio:
$ svn checkout svn://servidor/usr/local/repositorios/proyecto
Para incrementar la seguridad puede limitarse el acceso a un subdirectorio
empleando el par
ametro -r.
12

$ svnserve -d -r /usr/local/repositorios
De esta forma se accedera:
$ svn checkout svn://servidor/proyecto
8.1.1.

Autenticaci
on y autorizaci
on

Archivo de usuarios y realm En el archivo svnserve.conf, dentro del directorio conf/ del repositorio, bajo la seccion [general] se especifican: el archivo
que contiene los usuarios, el nombre de repositorio y los controles de acceso en
funci
on de si se es un usuario autentificado o no.
svnserve.conf
[general]
password-db = archivo_contrase~
nas # Ruta absoluta o relativa
realm = Ejemplo
anon-access = read # Los usuarios an
onimos s
olo pueden leer.
auth-access = write # Los usuarios registrados pueden escribir.
Los permisos pueden ser: none, sin acceso; read, solo lectura; write, lectura
y escritura.
nas (el indicado en password-db)
archivo contrase
[users]
juan = juanpasswd
ana = anapasswd
Puede ajustarse los permisos por directorios dentro de un repositorio, pero
eso no se cubrir
a en este documento.
SSH Lo c
omodo del metodo anterior es que no es necesario crear cuentas del
sistema por cada usuario, pero si se quiere aprovechar las cuentas de usuarios
puede usarse svnserve a traves de un t
unel SSH.
Basta con usar la ruta de la forma: svn+ssh://servidor/repositorio
Como en la forja se utiliza el metodo del archivo de usuarios por cada repositorio, si quiere m
as informacion sobre esta posibilidad, consulte [4]

8.2.

Apache httpd

Un repositorio puede hacerse accesible a traves del servidor Apache y un

m
odulo, usando el protocolo WebDAV[3], una extension del protocolo HTTP.
Para obtener informaci
on sobre como configurar un servidor Apache, puede
consultar [1]
Debe tener instalado el servidor Apache httpd 2.0, el modulo mod dav (que
viene con el servidor) y mod dav svn.
Una vez este todo instalado, aseg
urese de que ambos modulos sean cargados
al iniciar Apache. Puede hacerse en versiones antiguas a
nadiendo en httpd.conf
13

LoadModule dav_module
LoadModule dav_svn_module

modules/mod_dav.so
modules/mod_dav_svn.so

O, en versiones m
as reciente, a traves de /etc/apache2/mods-enabled, creando en su interior enlaces simbolicos a los modulos dav.load y a dav svn.load
situados en /etc/apache2/mods-available.
Una vez hecho esto es necesario hacer accesible el repositorio, lo que se puede hacer de dos formas, o haciendo accesible u
nicamente el repositorio de un
proyecto o el directorio que contiene los repositorios de varios proyectos. Esta
segunda forma es la u
til en el caso de la forja. Para que Apache sepa que directorio debe hacer accesible, escriba en el archivo httpd.conf o apache2.conf
(dependiendo de la versi
on):
<Location /svn>
DAV svn
SVNParentPath /usr/local/repositorio
</Location>
8.2.1.

Autenticaci
on

Autenticaci
on HTTP b
asica Usando la utilidad htpasswd que proporciona Apache. Lo primero es a
nadir los usuarios y sus contrase
nas:
# Se pasa el par
ametro -c para crear el archivo.
# -m es para cifrar la contrase~
na usando MD5
$ htpasswd -cm /etc/svn-auth juan
New password: ****
Re-type new password: ****
Adding password for user juan
$ htpasswd -m /etc/svn-auth ana
New password: ***
Re-type new password: ***
Adding password for user ana
Una vez hecho esto, es necesario especificar en el fichero de configuracion
que se quiere emplear este fichero para la autenticacion:
<Location /svn>
DAV svn
SVNParentPath /usr/local/repositorio
AuthType basic
AuthName "Subversion"
AuthUserFile /etc/svn-auth
Require valid-user # Todas las conexiones deben ser identificadas
</Location>

14

Certificado SSL Tambien pueden usarse conexiones seguras (https), pero

c
omo generar certificados y configurar Apache para que los use se escapa de los
objetivos de esta gua. Puede consultar el manual de Apache si le interesa el
tema.
8.2.2.

Opciones de acceso

Con las opciones anteriores cualquier usuario autenticado puede escribir y

leer del repositorio, mientras que los no autenticados no pueden leerlo.
Si se quiere permitir a los usuarios anonimos leer y a los registrados leer y
escribir:
<Location /svn>
DAV svn
SVNParentPath /usr/local/repositorio
AuthType basic
AuthName "Subversion"
AuthUserFile /etc/svn-auth
<LimitExcept GET PROPFIND OPTIONS REPORT>
# Hace falta identificarse salvo para las operaciones de lectura
Require valid-user
</LimitExcept>
</Location>
Empleando el m
odulo mod authz svn puede limitarse el acceso por directorios. Para m
as informaci
on al respecto, consulte [4], ya que esta mas alla de
esta gua r
apida.

Referencias
[1] Apache httpd. http://httpd.apache.org/.
[2] Detailed description of unified format. http://www.gnu.org/software/
diffutils/manual/html node/Detailed-Unified.html.
[3] Webdav. http://www.webdav.org.
[4] C.Michael Pilato Ben Collins-Sussman, Brian W. Fitzpatrick. Version Control with Subversion. TBA, 2004.

15