Su repositorio no está corrupto, ni sus datos perdidos. Si su proceso accede directamente al repositorio (mod_dav_svn, svnlook, svnadmin, o si accede a una URL file://), entonces está usando Berkeley DB para acceder a sus datos. Berkeley DB es un sistema transaccional, lo que significa que registra todo sobre lo que va a hacer antes de hacerlo. Si su proceso es interrumpido (por ejemplo por una señal kill o segfault), entonces un fichero de bloqueo se deja atrás, junto con un fichero de registro que describe el trabajo inacabado. Cualquier otro proceso que procure tener acceso a la base de datos se colgará, esperando a que desaparezca el fichero de bloqueo. Para despertar su repositorio, necesita pedirle a Berkeley DB que finalice el trabajo, o rebobinar la base de datos a un estado anterior que se sepa que es consistente.

Asegúrese que ejecuta este comando como el usuario que posee y administra la base de datos, no como superusuario, o sino dejará ficheros pertenecientes al superusuarioen el directorio db. Estos ficheros no pueden ser abiertos por el usuario no root que administra la base de datos, que típicamente es usted o su proceso Apache. También asegúrese de tener fijada correctamente la umask cuando ejecute la recuperación, si falla esta bloqueará a usuarios que están en el grupo permitido para acceder al repositorio.

Simplemente ejecute:

$ svnadmin recover /path/to/repos

Una vez el comando se haya completado, compruebe los permisos en el directorio db/ del repositorio.

La copia de trabajo de Subversion, como el Berkeley DB, usa un mecanismo transaccional para realizar todas las acciones. Esto es, registra todo acerca de lo que va a hacer antes de hacerlo. Si svn es interrumpido mientras realiza una acción, entonces uno o más ficheros de bloqueo son dejados atrás, junto con ficheros de registro describiendo las acciones inacabadas. (svn statusmostrará una L al lado de los directorios bloqueados.)

Cualquier otro proceso que intente tener acceso a la copia de trabajo fallará cuando vea los bloqueos. Para despertar su copia de trabajo, usted necesita pedirle al cliente que finalice el trabajo. Para corregir esto, ejecute este comando desde lo alto de su copia de trabajo:

$ svn cleanup

Vea “Cada vez que intento acceder a mi repositorio, mi cliente de Subversion se cuelga”.

También puede tener un problema de permisos al abrir el repositorio. Vea “Ofrecer múltiples métodos de acceso al repositorio”.

Vea URLs del repositorio.

Si la importación funciona bien sobre acceso local:

$ mkdir test
$ touch test/testfile
$ svn import test file:///var/svn/test -m "Initial import"
Adding         test/testfile
Transmitting file data .
Committed revision 1.

Pero no desde un puesto remoto:

$ svn import test http://svn.red-bean.com/test -m "Initial import"
harry's password: xxxxxxx

svn_error: … The specified activity does not exist.

Hemos visto esto cuando el directorio REPOS/dav/ no tiene permisos de escritura para el proceso httpd. Compruebe los permisos para asegurarse que el httpd de Apache puede escribir en el directorio dav/ (y al directorio correspondiente db/, por supuesto).

Necesita instalar Windows XP Service Pack 1 para corregir un fallo en la pila TCP/IP en el sistema operativo. Puede conseguir toda clase de información sobre este Service Pack en http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949.

Utilice Ethereal para cuchichearla conversación:

	Nota
	Las siguientes instrucciones son especificas para la versión gráfica de Ethereal, y puede no ser aplicable a la versión de linea de comandos (cuyo binario se nombra generalmente tethereal).

Alternativamente, usted puede fijar un parámetro en el fichero servers de configuración de tiempo de ejecución de su cliente para hacer aparecer la salida depurada. El valor numérico de neon-debug es una combinación de los valores NE_DBG_* en el fichero de cabecera ne_utils.h. Fijando la variable neon-debug-mask a 130 (por ejemplo NE_DBG_HTTP + NE_DBG_HTTPBODY) hará que los datos de HTTP sean mostrados.

Usted puede querer inhabilitar la compresión al hacer una traza de red arreglando el parámetro http-compression en el mismo fichero.

Subversion usa un sistema de plugins para permitir el acceso a los repositorios.Actualmente hay tres de estos plugins: ra_local permite el acceso a un repositorio local, ra_dav permite el acceso a un repositorio vía WebDAV, y ra_svn permite el acceso local o remoto vía el servidor svnserve. Cuando intente realizar una operación en subversion, el programa intenta cargar dinámicamente un plugin basado en el esquema de URL. Una URL file:// intentará cargar ra_local, y una URL http:// intentará cargar ra_dav.

El error que usted está viendo significa que el enlazador/cargador dinámico no puede encontrar los plugins a cargar. Esto normalmente ocurre cuando compila subversion con librerías compartidas, entonces intentar ejecutarlo sin ejecutar primero 'make install'. Otra causa posible es que usted ejecutó make install, pero las librerías fueron instaladas en una ubicación que el enlazador/cargador dinámico no reconoce. Bajo Linux, usted puede permitir al enlazador/cargador buscar las librerías añadiendo el directorio de biblioteca a /etc/ld.so.conf y ejecutando ldconfig. Si no desea hacer esto, o no tiene acceso de root, usted también puede especificar el directorio de librería en la variable de entorno LD_LIBRARY_PATH.

La respuesta corta: es para su propio bien.

Subversion pone una prioridad muy alta en la protección de sus datos, y no solo en sus datos versionados. Las modificaciones que usted hace a los ficheros recién versionados, y los nuevos ficheros programados para ser añadidos al sistema de control de versiones, deben ser tratados con cuidado.

Haciendo el comando svn revert requiere un objetivo explícito—incluso si este objetivo es '.'—es una manera de lograr eso. Este requisito (así como requerirle para proveer el parámetro --recursive si usted desea este comportamiento) está pensado para hacerle pensar realmente que está haciendo, porque una vez que se invierten sus ficheros, sus modificaciones locales se van para siempre.

Su apr-util está enlazado contra DB-3, y svn enlazado contra DB-4. Desafortunadamente, los símbolos de la BD no son diferentes. Cuando mod_dav_svn está cargado en el espacio de proceso de Apache, termina resolviendo los nombres de los símbolos contra la librería DB-3 de apr-util.

La solución es asegurarse de que apr-util compila contra DB-4. Puede hacer esto pasando opciones específicas al fichero de configuración de apr-util o al de apache: "--with-dbm=db4 --with-berkeley-db=/the/db/prefix".

Esto realmente no es un problema con Subversion, pero afecta a menudo a usuarios de Subversion.

RedHat 9 y Fedora vienen con una librería de Berkeley DB que confía en el soporte del núcleo para NPTL (la Librería Posix Nativa de Threads). Los núcleos que proporciona RedHat tiene este soporte incluido, pero si usted compila su propio núcleo, entonces puede no tener el soporte para NPTL. Si este es el caso, entonces usted verá errores como estos:

svn: Berkeley DB error
svn: Berkeley DB error while creating environment for filesystem tester/db:
Function not implemented

Esto puede ser arreglado en una de varias maneras:

Si usted permite acceso anónimo de escritura al repositorio vía Apache, el servidor Apache nunca pide al cliente un nombre de usuario, y en lugar de eso permite la operación de escritura sin autenticación. Dado que Subversion no tiene ni idea de quien hizo la operación, esto da lugar a un registro como este:

$ svn log
------------------------------------------------------------------------
rev 24:  (no author) | 2003-07-29 19:28:35 +0200 (Tue, 29 Jul 2003)
…

Lea sobre añadir autenticación en Capítulo 6, Configuración del servidor.

Éstos aparecen debido a varios servicios de Windows que supervisan el sistema de ficheros en busca de cambios (software antivirus, servicios de indexado, el COM+ Event Notification Service). Esto realmente no es un bug en Subversion, lo que lo hace difícil de corregir. Un resumen del estado actual de investigación está disponible en http://www.contactor.se/~dast/svn/archive-2003-10/0136.shtml. Un trabajo que debe reducir la tasa de incidencias para la mayoría de la gente fue implementada en la revisión 7598.

Generalmente esto es debido a una carencia de la entropía disponible en el sistema. Subversion pide a APR generar números aleatorios para crear UUIds de tiempo en tiempo, y ciertos sistemas operativos se bloquearán para la aleatoriedad de alta calidad. Usted probablemente necesite configurar el sistema para recolectar entropía de fuentes tales como interrupciones de disco duro y de la red. Consulte las páginas de manual de su sistema, específicamente random(4) y rndcontrol(8) en cómo efectuar este cambio. Otro trabajo es compilar APR contra /dev/urandom en vez de /dev/random.

Esto significa que su httpd.conf está sin configurar. Generalmente este error ocurre cuando ha definido la "ubicación" virtual para existir dentro de dos alcances al mismo tiempo.

Por ejemplo, si ha exportado un repositorio como <Location /www/foo>, pero también ha definido su DocumentRoot para ser /www, entonces usted está en apuros. Cuando la petición viene para /www/foo/bar, apache no sabe si encontrar un fichero real llamado /foo/bar dentro de su DocumentRoot, o si pedir a mod_dav_svn para obtener un fichero /bar del repositorio /www/foo. Generalmente el caso formado gana, y aparece el error "Movido Permanentemente".

La solución es asegurarse que su repositorio <Location> no solape o viva dentro de cualquier área ya exportada como parte normal de intercambio web.

Una buena característica de Subversion es que el repositorio entiende las copias y los renombrados, y preserva las conexiones históricas. Por ejemplo, si usted copia /trunk a /branches/mybranch, entones el repositorio entiende que cada fichero en la rama tiene un "predecesor" en el tronco. Ejecutando svn log --verbose le mostrará la copia histórica, así que usted puede ver el renombrado:

r7932 | jose | 2003-12-03 17:54:02 -0600 (Wed, 03 Dec 2003) | 1 line
Changed paths:
   A /branches/mybranch (from /trunk:7931)

Desafortunadamente, mientras el repositorio está enterado de las copias y renombres, casi todos los subcomandos del cliente svn con versión 1.0 no están enterados. Comandos como svn diff, svn merge, y svn cat es necesario que entiendan y sigan los renombrados, pero todavía no hace esto. Esto está programado como una característica post-1.0. Por ejemplo, si hace a svn diff comparar dos versiones anteriores de /branches/mybranch/foo.c, el comando no entenderá automáticamente que la tarea requiere realmente comparar dos versiones de /trunk/foo.c, debido al renombrado. En su lugar, usted verá un error sobre cómo la ruta de la rama no existe en las versiones anteriores.

La solución para todos los problemas de este tipo es hacer el trabajo sucio usted mismo. Esto es, usted necesita ser conocedorde cualquier ruta renombrada, descubriéndolos usted mismo usando svn log -v, y después proporcionelos explícitamente al cliente de svn. Por ejemplo, en vez de ejecutar

$ svn diff -r 1000:2000 http://host/repos/branches/mybranch/foo.c
svn: Filesystem has no item
svn: '/branches/mybranch/foo.c' not found in the repository at revision 1000

...en su lugar usted debería ejecutar

$ svn diff -r1000:2000 http://host/repos/trunk/foo.c
...