Hay un número de problemas que usted puede encontrar en el transcurso de instalar y usar Subversion. Algunos de estos serán resueltos una vez que usted tenga una mejor idea de cómo hace las cosas Subversion, mientras que otros son causados porque usted está acostumbrado a la manera de funcionar de otros sistemas de control de versiones. Otros problemas pueden ser insalvables debido a fallos en alguno de los sistemas operativos donde Subversion funciona (considerando la amplia gama de SO donde Subversion funciona, es asombroso que no encontramos demasiados de éstos).
La siguiente lista ha sido completada en el transcurso de años
de usar
Subversion. Si no puede encontrar aquí el problema que está teniendo,
mire la versión más actualizada del FAQ en el página web principal de
Subversion. Si todavía está atascado,
entonces envíe un email a <users@subversion.tigris.org>
con una descripción detallada del problema que está teniendo.
[57]
Aquí hay algunas de las preguntas más populares del FAQ de Subversion.
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). |
Desplegar el menú Capture, y elija Start.
Escriba puerto 80 para Filter, y desactive el modo promiscuo.
Ejecute su cliente Subversion.
Pulse Stop. Ahora usted tiene una captura. Parece una lista enorme de lineas.
Haga clic en la columna Protocol para abreviar.
Después, haga clic en la primera linea relevante TCP para seleccionarla.
Clic derecho, y elija "Follow TCP Stream". Le presentarán los pares petición/respuesta de la conversión del HTTP del cliente de Subversion.
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:
Reconstruir db4 para el núcleo que usted está usando.
Usar un núcleo de RedHat 9.
Aplicar los parches NPTL al núcleo que está usando.
Usar un núcleo reciente (2.5.x) con soporte NPTL incluido.
Comprobar si la variable de entorno
LD_ASSUME_KERNEL
está definida como 2.2.5,
y si es así, desasignarla antes de
arrancar Subversion (Apache). (Generalmente usted fijaría
esta variable para ejecutar Wine o Winex en RedHat 9)
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 ...
[57] Recuerde que la cantidad de detalle que provea sobre su configuración y su problema es directamente proporcional a la probabilidad de conseguir una respuesta de la lista de correo. Está animado a incluir brevemente lo que ha tomado para desayunar o el nombre de soltera de su madre.