Crear un repositorio Subversion es una tarea increíblemente simple. La utilidad svnadmin, provista con Subversion, tiene un subcomando justo para esto. Para crear un nuevo repositorio, ejecuta:
$ svnadmin create /path/to/repos
Crea un nuevo repositorio en el directorio
/path/to/repos. Dicho nuevo repositorio comienza
su vida en la revisión 0, que se define como nada excepto el directorio raíz
(/) del sistema de ficheros. Inicialmente,
la revisión 0 tiene también una única propiedad de revisión,
svn:date, que tiene la hora a la que el
el repositorio fue creado.
![[Aviso]](images/warning.png)
|
Aviso |
|---|---|
|
No crees tu repositorio en una unidad de red compartida —no puede existir un un sistema de ficheros remoto como NFS, AFS, o Windows SMB. La base de datos Berkeley necesita que el sistema de ficheros subyacente implemente estrictamente la semántica de bloqueo POSIX, y más importante, la habilidad para mapear ficheros directamente Casi ningún sistema de ficheros de red tiene estas características. Si intentas usar una base de datos Berkeley en una unidad compartida de red, los resultados son impredecibles —puede que veas errores misteriosos, o pueden pasar meses hasta que descubras que la base de datos de tu repositorio está sutilmente corrupta. Si necesitas que varios ordenadores accedan al repositorio, deberías instalar un proceso servidor ( como Apache o svnserve), almacenar el repositorio en un sistema de ficheros local al que el servidor pueda acceder, y hacer que el repositorio esté disponible por la red. Capítulo 6, Configuración del servidor se ocupa de este proceso en detalle. |
Te habrás dado cuenta de que el argumento de ruta de
svnadmin fue sólo una ruta normal del sistema
de ficheros y no una URL como la que el programa cliente
svn usa cuando se refiere a los repositorios.
Tanto svnadmin como svnlook
son considerados como utilidades del lado del servidor—
se usan en la máquina donde reside el repositorio para examinar
o modificar aspectos del mismo, y son de hecho, tareas imposibles
de realizar por red. Un error común hecho por recién llegados a
Subversion es tratar de pasar URLs ( incluso las file:
“locales” ) a ambos programas.
Así, después de que hayas ejecutado el comando svnadmin create, tienes un nuevo y brillante repositorio Subversion en su propio directorio. Echemos una ojeada a qué es lo que realmente se crea dentro de ese subdirectorio.
$ ls repos conf/ dav/ db/ format hooks/ locks/ README.txt
Con la excepción de los ficheros README.txt y
format, el directorio del repositorio es un grupo
de subdirectorios. Al igual que en otras áreas del diseño de Subversion,
se le tiene mucho respeto a la modularidad, y se prefiere una
organización jerárquica antes que un caos que estorbe. He aquí una breve
descripción de todos los objetos que puedes ver en tu nuevo directorio
de repositorio:
- conf
-
Un directorio que contiene los ficheros de configuración del repositorio.
- dav
-
Un directorio para Apache y mod_dav_svn y su economía privada de datos.
- db
-
El entorno principal de la base de datos Berkeley, lleno de tablas que el almacenamiento de datos para el sistema de ficheros de Subversion ( donde todos tus datos versionados residen.
- format
-
Un fichero cuyo contenido es un simple valor entero que nos dice el número de versión del repositorio
- hooks
-
Un directorio lleno de plantillas de ganchos (y los mismos ganchos), una vez que hayas instalados algunos.
- locks
-
Un directorio para el bloqueo de datos de repositorio de Subversion, usado para los accesos al repositorio.
- README.txt
-
Un fichero que simplemente informa a sus lectores que están mirando un repositorio Subversion.
En general, no deberías con tu repositorio “a mano”. La herramienta svnadmin debería ser suficiente para cualquier cambio necesarios en tu repositorio, o puedes echar una ojeada a herramientas de terceros ( como la suitede herramientas de la base de datos Berkeley ) para subsecciones relevantes del repositorio. Sin embargo, hay algunas excepciones, y las veremos aquí.
Un gancho es un programa activado por algún evento del repositorio, como la creación de una nueva revisión o la modificación de una propiedad no versionada. A cada gancho se le da suficiente información para que sepa de qué evento se trata, cuál es su objetivo, y el nombre de usuario de la persona que disparó el evento. Dependiendo de la salida del gancho o de estado de su salida, el programa de enganche puede continuar la acción, pararla, o suspenderla de alguna manera.
El subdirectorio hooks se rellena,
por defecto, con plantillas para varios ganchos de repositorio.
$ ls repos/hooks/ post-commit.tmpl pre-revprop-change.tmpl post-revprop-change.tmpl start-commit.tmpl pre-commit.tmpl
Hay una plantilla por cada gancho que implementa el repositorio
Subversion, y examinando los contenidos de dichas plantillas
de scripts, puede ver qué disparador ejecuta
cada script y qué datos se le pasan. También se encuentran
en muchas de estas plantillas ejemplos de cómo debería usar
dicho script, conjuntamente con otros programas provistos
por Subversion, para realizar tareas comunes y útiles. Para instalar
realmente un gancho funcional, sólo necesita colocar algún ejecutable
o script en el directorio repos/hooks que pueda
ser ejecutado con el nombre del gancho ( como start-commit
o post-commit).
En plataformas Unix, esto significa proveer un script o
programa (podría ser un shell script, un programa Python,
un binario C compilado, o cualquier otra cosa) llamado
exactamente igual que el nombre del gancho. Por supuesto,
los ficheros de plantillas están presentes para algo más
que sólo propósitos informativos—la manera más fácil de
instalar un gancho en plataformas Unix es simplemente copiar
el fichero de plantilla apropiado en un nuevo fichero sin la
extensión .tmpl, personalizando los contenidos
del gancho, y asegurándose de que el script sea ejecutable.
Windows, sin embargo, usa extensiones de fichero para determinar
si un programa es ejecutable o no, así que debería dar poner
un programa cuyo nombre sea el nombre del gancho, y cuya extensión
sea una de las extensiones especiales reconocidas por Windows
como ficheros ejecutables, como .exe o
.com para programas, y .bat
para ficheros de scripts.
Actualmente hay cinco ganchos implementados por el repositorio Subversion:
-
start-commit -
Se ejecuta antes de la transacción de envío haya sido creada. Se usa normalmente para decidir si el usuario tiene los privilegios suficientes. El repositorio pasa dos argumentos a este programa: la ruta al repositorio, y el nombre de usuario que intenta realizar el envío. Si el programa devuelve algún valor distinto de cero, se paraliza el envío antes de haber creado la transacción.
-
pre-commit -
Se ejecuta cuando se completa la transacción, pero antes de ser enviados los datos al repositorio. Este gancho se usa normalmente como protección contra envíos que no se permiten debido a contenido o ubicación ( por ejemplo, su sitio puede requerir que todos los cambios sobre una rama determinada incluyan un número de ticket del seguimiento de fallos, o que el mensaje de informe de cambios entrante no esté vacío). El repositorio pasa dos argumentos a este programa: la ruta al repositorio, y el nombre de la transacción que va a sufrir el cambio. Si el programa devuelve una salida que no sea cero, el envío se aborta y la transacción se borra.
La distribución Subversion incluye algunos scripts de control de acceso ( ubicados en el directorio
tools/hook-scriptsdel árbol de fuentes de Subversion ) a los que se puede llamar desde pre-commit para implementar un control de de acceso más en detalle. En estos momentos, esta es la única manera por la cual los administradores pueden controlar el acceso más allá de lo que el ficherohttpd.confde Apache ofrece. En una versión futura de Subversion, planeamos implementar listas de control de acceso (ACLs) directamente en el sistema de ficheros. -
post-commit -
Esto se ejecuta después de que la transacción se haya confirmado, y una nueva revisión haya sido creada. La mayoría de la gente usa este gancho para enviar correos descriptivos acerca de la confirmación o para hacer una copia de seguridad del repositorio. El repositorio pasa dos argumentos a este programa: la ruta al repositorio, y el número de la nueva revisión creada. El código de salida del programa es ignorado.
La distribución de Subversion incluye un script commit-email.pl ( ubicado en el directorio
tools/hook-scripts/del árbol de fuentes de Subversion ) que puede ser usado para enviar correos electrónicos con ( añadiendo o no un fichero de log ) una descripción de la confirmación hecha. Este correo contiene una lista de las rutas que fueron cambiadas, el mensaje de log adjunto a la confirmación, el autor y fecha de la confirmación, así como un informe en formato de GNU diff de los cambios hechos en los ficheros versionados como parte de la confirmación.Otra herramienta útil de Subversion es el script hot-backup.py ( ubicado en el directorio
tools/backup/del árbol de fuentes de Subversion ). Este script realiza copias de seguridad en caliente de su repositorio Subversion ( una capacidad soportada por el motor de bases de datos Berkeley), y puede ser usada para hacer una foto por cada confirmación de su repositorio para archivar, o con el objetivo de recuperación de emergencia. -
pre-revprop-change -
Al no ser versionadas las propiedades de revisión de Subversion, hacer modificaciones a una de ellas ( como por ejemplo, el mensaje de informe de cambios
svn:log) sobreescribirá el valor previo de esa propiedad para siempre. Como hay datos aquí que potencialmente se pueden perder, Subversion provee este gancho ( y su contrapartida,post-revprop-change) de tal manera que los administradores de repositorios puedan mantener con métodos externos si así lo desean, registros de los cambios de dichas propiedades. Como precaución contra la pérdida de datos de propiedades no versionadas, no se permite a los clientes Subversion modificarlos del todo remotamente a no ser que este gancho se implemente para su repositorio.Este gancho se ejecuta justo antes de que una modificación de este tipo se haga en el repositorio. El repositorio pasa cuatro argumentos al gancho: la ruta al repositorio, la revisión en la cual la propiedad que se va a modificar existe, el nombre autenticado de usuario de la persona que va a hacer el cambio, y el nombre mismo de la propiedad.
-
post-revprop-change -
Como se ha mencionado antes, este gancho es la contrapartida del gancho
pre-revprop-change. De hecho, por paranoia, este script no se ejecutará a no ser que el ganchopre-revprop-changeexista. Cuando ambos están presentes, el ganchopost-revprop-changese ejecuta justo después de que una propiedad de revisión haya sido modificad, y se usa típicamente para enviar un correo electrónico con el nuevo valor de la propiedad cambiada. El repositorio pasa cuatro argumentos al gancho: la ruta al repositorio, la revisión en la cual la propiedad existe, el nombre autenticado de usuario de la persona que va a hacer el cambio y el nombre mismo de la propiedad.La distribución de Subversion incluye el script propchange-email.pl script (ubicado en el directorio
tools/hook-scripts/del árbol de fuentes de Subversion ) que puede ser usado para enviar un correo electrónico con ( y/o añadido a un fichero de log ) los detalles de un cambio en una propiedad de revisión. Este correo electrónico contiene la revisión y nombre de la propiedad modificada, el usuario que hizo el cambio, y el nuevo valor.
Subversión tratará de ejecutar los ganchos como el mismo usuario que posee el proceso que está accediendo al repositorio Subversion. En la mayoría de los casos, el repositorio se accede a través del servidor HTTP Apache y mod_dav_svn, así que este usuario es el mismo que el usuario con el que se ejecuta Apache. Los mismos ganchos necesitarán ser configurados con permisos a nivel de sistema operativo que les permitan ser ejecutados por dicho usuario. Asimismo, esto significa que cualquier fichero o programas ( incluyendo el repositorio mismo ) al que acceda directa o indirectamente el gancho, será a través del mismo usuario. En otras palabras, esté alerta a problemas potenciales relacionados con permisos que impidan al gancho realizar las tareas para las cuales lo haya escrito.
Un entorno de base de datos Berkeley es una encapsulación de una o más bases de datos, ficheros de registro, ficheros regionales y ficheros de configuración. El entorno de base de datos Berkeley tiene su propio conjunto de valores de configuración por defecto para cosas como el número de bloqueos que se permite eliminar de una sola vez, o el tamaño máximo de los ficheros de registro , etc. El código del sistema de ficheros de Subversion elige además valores por defecto para algunas de las opciones de configuración de la base de datos Berkeley. De todas maneras, algunas veces su repositorio particular, con su colección única de datos y patrones de acceso, podría necesitar un grupo diferente de valores de configuración.
La gente de Sleepycat ( los programadores de la base de datos
Berkeley ) entienden que bases de datos diferentes, tienen
requerimientos específicos, de tal manera, que nos proveen
de un mecanismo para sobreescribir en tiempo de ejecución,
muchos de los valores de configuración del entorno Berkeley.
Berkeley comprueba la presencia de un fichero denominado
DB_CONFIG en cada directorio del entorno,
y las opciones que encuentra en dicho
fichero para usarlas en ese entorno Berkeley particular.
El fichero de configuración de Berkeley para su repositorio
se encuentra en directorio del entorno db,
en repos/db/DB_CONFIG. Subversion crea
por sí mismo el fichero al mismo tiempo que el resto del repositorio.
El fichero inicialmente contiene algunas opciones por defecto,
así como enlaces a la documentación en línea de la base de datos Berkeley
de tal manera que pueda saber qué significan dichas opciones.
Por supuesto, es libre de añadir cualquiera de las opciones soportadas
por la base de datos Berkeley a su fichero DB_CONFIG.
Tan sólo tenga cuidado porque mientras Subversion no trata de
leer o interpretar los contenidos del fichero, y no hace uso
de sus opciones de configuración, tendrá que evitar cualquier
cambio en la configuración que pueda causar que la base de datos Berkeley
se comporte de una manera inesperada para el resto del código
de Subversion. Por otra parte, los cambios hechos en
DB_CONFIG no tendrán efecto hasta que
vuelva a leer en entorno de la base de datos ( usando
svnadmin recover).