Administracion
Un conjunto de directorios y archivos diseñados de manera que, cuando se accede a él mediante las herramientas de svn, se comporta como un auténtico sistema de ficheros en el que no se pierden los cambios hechos a los ficheros.
Un solo repositorio para todos los proyectos o un repo para cada proyecto.
Un solo repo puede parecer más fácil de mantener, y en efecto lo es: en caso de cambio de versión de subversion, basta migrar un solo repo. Pero no es lo más adecuado pues:
El layout de cada proyecto debería incluir los directorio trunk, branches y tags.
Aunque hay muchas maneras de hacerlo, todas giran alrededor de una de estas 4 estrategias:
Personalmente opto por la segunda, aunque la instalación y configuración no es la más sencilla, tampoco es demasiado complicada. Además una vez puesto en marcha el mantenimiento es muy fácil y permite controlar no solo la autenticación sino también la autorización. Por otro lado es la instalación más completa.
EN este enlace del libro oficial se habla de las opciones de servidores de subversion.
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.serverconfig.choosing
Un tutorial con la instalación mediante webdav se puede ver aquí:
http://juandarodriguez.es/instalacion-svn-server.html
Y otro tutorial sobre la instalación mediante el demonio svnadmin y ssh aquí:
Dos posibilidades:
Por defecto se usa el sistema de ficheros. La portabilidad es uno de las características por la que se suele preferir el sistema de ficheros. También el hecho de quitar una dependencia en la instalación (la base de datos). Además la base de datos de Berkeley no es Platform-independent y es más lenta que el sistema de ficheros.
La única cosa que mejora la opción DB Berkeley es la escalabilidad, parece que algunos sistemas de ficheros antiguos no escalan bien con miles de entradas en un mismo directorio. Como cada revisión se almacena en un archivo, cuando el proyecto alcanza un nº de revisiones suficientemente grande, puede suponer un problema de rendimiento en esos sistemas de ficheros antiguos.
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.basics.backends.tbl-1
Donde quiera que se haya decidido crear el repositorio:
Si se desea usar el sistema de ficheros como backend:
svnadmin create /var/svn/repos
Y si se desea usar una base de datos de berkeley:
svnadmin create --fs-type bdb /var/svn/repos
Los hooks son procedimientos que se ejecutan cuando ciertos eventos ocurren. Tenemos pre-hooks, que ocurren justo antes de que la operación sobre el repo ocurra y los post-hooks que ocurren justo después.
Los hooks se ubican en el directorio hooks del repositorio y se deben llamar:
donde {action} puede ser:
En el directorio hooks se encuentran algunas plantillas de hooks que se pueden utilizar como modelo para implementar la que nos haga falta. Basta copiar una de ellas quitar la extensión tmpl y modificarla según se requiera.
consultar la ayuda (svn[tool] help) de cada uno de estos comandos para ver los que se puede hacer con ellos.
svnadmin también proporciona herramientas para tratar con repositorios que usen la base de datos de Berkely como backend.
ver http://www.oracle.com/technology/documentation/berkeley-db/db/
Por defecto subversion no deja cambiar los mensajes de logs a los usuarios (ni ninguna otra propiedad de revisiones. Aunque este comportamiento se puede cambiar usando el pre-revprop-change hook), un administrador si que puede cambiarlo de la siguiente manera:
echo "Here is the new, correct log message" > newlog.txt
$ svnadmin setlog myrepos newlog.txt -r 388 --bypass-hook
Una utilidad interesante para cuando se tiene un gran nº de revisiones y el nº de archivos ha crecido mucho es empaquetar el sistema de ficheros FSFS:
svnadmin pack /var/svn/repos
Con esto se consigue empaquetar todos los archivos de todas las revisiones en un solo archivo.