Subversion COMO / Subversion HOWTO

Esto es una explicacion sobre como se ha montado el servicio subversion en la maquina de Aditel, para dar este servicio respetando las contraseñas de los usuarios y permitir desarrolladores en los proyectos sin cuenta local y ademas proporcionar acceso anonimo a los repositorios.

[Nota aclaratoria]
La maquina donde se a montado se llama devnull :)

Vamos a asociar mentalmente usuarios reales de devnull (usuarios que
tienen acceso por ssh) con una cuenta para el repositorio.

También asociaremos cada proyecto con un grupo en devnull
(svn-proyecto o proyecto) que además se podría vincular con el resto
de recursos del proyecto (web, etc...)

Además vamos a añadir un usuario nuevo 'svn' o 'svnadmin' que sera el
que ejecutara ciertos procesos y tendrá algunos privilegios.

Los integrantes del cada proyecto pertenecen a ese grupo. Además el
usuario especial svnadmin pertenece a todos los grupos de proyectos.

Ahora vamos a ver si consigo explicar el tinglado...

Cualquier socio se puede crear su repositorio subversion en su home
fácilmente:
user@devnull$ mkdir ~/svnroot
user@devnull$ svnadmin create ~/svnroot/proj

Y acceder a él remotamente para usarlo como repositorio para sus cosas
con:
yo@casa$ svn co svn+ssh://user@devnull/home/user/svnroot/proj.
[cualquier comando de subversion]

Con esto el usuario se ha montado su repositorio privado, para el, que
se autentica por ssh. Pero no puede compartirlo con otros usuarios de
devnull porque no tendrán permisos para escribir en los ficheros del
repositorio de devnull (Mientras haya autenticación por ssh poder
modificar ficheros o cualquier otra operación sobre los repositorios
significa tener el mismo poder sobre los ficheros de la copia maestra,
es, en cierto modo, como manipular los ficheros del repositorio
directamente).

En cambio puede ofrecer este repositorio de forma pública y anónima y a
cualquiera ejecutando el siguiente proceso que se quedaría en segundo
plano sirviendo el repositorio:
user@devnull$ svnserve -d -r ~/svnroot

Con lo que alguien de matalascañas podría bajarlo con:
alguien@matalascañas$ svn co svn://devnull.aditel.org/proj

También nuestro socio 'listo' puede dar cuentas para modificar el
repositorio usando los ficheros de configuración de svnserver ubicados
en proj/conf/* y él podría usar autenticación por ssh:// o por svn://.

Ahora bien, si queremos evitar que 15 usuarios corran el mismo proceso
tenemos una opción:
- Cambiar el propietario del ejecutable svnserve a 'svnadmin' y dejarlos
permisos del mismo en 700.

Ahora bien, lo que nos interesa es crear un repositorio central con
todos los proyectos de Aditel de forma autenticada por ssh y además
pueda servirlos a usuarios anónimos:

Creamos /var/lib/svn/svn (si doble /svn/, ahora lo explico)
$ mkdir -p /var/lib/svn/svn

Creamos los repositorios para uno de los proyectos con:
$ svnadmin create /var/lib/svn/svn/proj-n

svnadmin debe pertenecer a todos los grupos que se creen para los
proyectos, para poder servirlos o por lo menos tener permisos de lectura
sobre los ficheros de los mismos.
Si svnadmin tiene ademas poder de escritura se puede ofrecer acceso rw
tanto por ssh:// como por svn:// es decir, gente no socia podría
participar en los proyectos ofrecidos por subversion.
Además svnadmin serviría para poder crear sin tener permisos de root
nuevos repositorios para proyectos y otras tareas administrativas.

Finalmente dejamos ejecutándose el proceso svnserve como usuario
svnadmin sirviendo estos repositorios para los usuarios anónimos:
$ su -c "svnserve -d -r /var/lib/svn/" svnadmin

Con esto la raíz del repositorio queda en /var/lib/svn con lo que para
descargar el repositorio se usaria:
$ svn co svn://devunll.aditel.org/svn/proj-n
Por eso el doble /svn/

El repositorio en devnull para cada proyecto debe tener unos permisos
adecuados que nos permitan administrarlo de forma cómoda.
- Todos lo nodos (ficheros y directorios) deben ser del grupo del
proyecto para que todos los integrantes del mismo grupo puedan hacer
cambios en el proyectos, creo que no se crean ficheros nuevos ni
subdirectorios, pero para evitar que se creen con grupo propietario
distinto se puede usar chmod g+s en los directorios.
- Si queremos que en un proyecto puedan colaborar personas externas a
devnull debemos dejar que el responsable del proyecto tenga control
sobre los ficheros conf/* del repositorio, en caso contrario hay que
evitar que tenga este control.
- La razón de que exista un usuario svnadmin y que pertenezca a todos
los grupos es para poder controlar estos permisos y simplificar la
administración de los repositorios.

Y eso es todo. Espero no haberme dejado nada por el camino.