2009-06-23 11 views
48

estoy recibiendo este error al tratar de comprometerse a un repositorio SVN:SVN: NKACTIVITY 403 Forbidden

svn: MKACTIVITY of '/svn/Demo/!svn/act/e2e65cfa-...4165f': 403 Forbidden (http://svn....com:8088) 

Cualquier idea de por qué? Busqué mucho en Google, pero no puedo encontrar una solución que funcione para mí.

+3

ve como un problema permissiosn –

+1

Sí, este error puede ocurrir cuando sólo se tiene acceso de lectura a un repositorio – PhilMY

+0

@PhilMY Eso no es cierto. –

Respuesta

22

Compruebe si ha proporcionado las credenciales correctas o si tiene suficientes derechos para llegar a ese repositorio (generalmente mirando los archivos authz, si puede administrar la configuración del servidor). Como dijo uno de los comentaristas anteriormente, es un problema de permiso.

+2

Tengo el problema después de haber cambiado la contraseña de mi Subersion pero no la contraseña guardada de TortoiseSVN. Publicar sobre cómo cambiar la contraseña de TortoiseSVN: http://stackoverflow.com/questions/4034026/how-to-change-password-using-tortoisesvn –

+2

Esto no funcionó para mí. En mi caso, fue un problema con el caso de URL como se describe en la respuesta de Stiefel: http://stackoverflow.com/a/3289512/1385405 y en esta publicación: http: //stackoverflow.com/a/57148/1385405 – gfrigon

+0

@gfrigon que funcionó –

2

Esto también puede ocurrir si el usuario coloca un espacio al final de su nombre de usuario. Nuestra configuración es svn a través de http en apache. Si un usuario coloca un espacio en blanco al final si su nombre de usuario, se recortará y apache pasará la autenticación. Sin embargo, svn no podrá encontrar el nombre de usuario y obtendrá este error bastante críptico.

También puede ocurrir debido a un problema de url extraño. Windows no hace una diferencia en el caso del sistema de archivos, pero svn sí (incluso cuando se ejecuta en Windows). Ver información en este here.

7

Doble casilla de verificación en la ruta del repositorio.

34

No sé si esta respuesta lo ayuda, pero en mi caso tenía algo que ver con los nombres de dominio del servidor y la distinción entre mayúsculas y minúsculas.

La URL que usamos para esta copia de trabajo fue

https://bhm18a.serona.org:8443/svn/nebeam/eco/branches/apple2010

en lugar de la URL correcta

https://bhm18a:8443/svn/NeBeam/eco/branches/apple2010

misteriously, la URL equivocada trabajó para "revisar" y "actualización "y navegando por el repositorio pero no por" copiar "o" confirmar ".

La comprobación de una nueva copia de trabajo con la URL exacta hizo desaparecer los problemas.

(1.6.12 Uso de la subversión con Visual SVN servidor instalado en un Microsoft Windows Server)

+2

¡Esta debería ser la respuesta correcta! –

+0

¡Esa es una respuesta correcta! –

+0

¡Funcionó para mí, gracias muchísimo! – attaboy182

0

ocurrió el error 403 Forbidden después de que modificara el .htaccess para limitar los métodos de petición con:

RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST|PROPFIND|OPTIONS|PUT)$ [NC] 
RewriteRule .* - [F,NS,L] 
5

Caso en la ruta del repositorio DEBE coincidir con el caso en el servidor. Pasé muchas horas rastreando por qué algunos usuarios podrían realizar cambios en el repositorio y otros no. Resulta que el pago inicial para los usuarios "prohibidos" se hizo con la URL en todas las minúsculas "../svn/robotconfig" cuando el nombre del repositorio era realmente "../svn/RobotConfig". Después de realizar un nuevo proceso de pago con el nombre del depósito debidamente encuadrado, los usuarios pudieron realizar cambios.

0

Me acaba de ocurrir esto al usar Eclipse con el complemento Subversivo. La realización de un Equipo> Limpieza en el proyecto lo solucionó.

2

El nombre de usuario de sensibilidad a mayúsculas/minúsculas fue el problema para mí. El administrador me dijo que mi nombre de usuario era ... "MyName", que funcionaba para el pago y la actualización, pero en la confirmación, se tenía que usar la minúscula "myname".

5

En mi caso, la "solución" era: el administrador estúpido en nuestra empresa simplemente cambió todo, desde SVN a GIT sin comunicar esto a los desarrolladores. Seriamente.

+3

lol, ¿en serio? suena no muy amable;) – Tobias

+0

Tuviste que venir. –

6

me encuentro con este problema todo el tiempo y

rm -rf ~/.subversion/auth 

siempre funciona para mí.

Elimine este directorio y luego intente volver a confirmar.

0

resolví esto, el problema es con las credenciales de edad que se almacenan en las siguientes carpetas \Users\<Your user name>\AppData\Roaming\Subversion\auth\svn .simple

acaba de tomar una copia de seguridad de los archivos de esta carpeta y eliminar todos y tratar de cometer de nuevo, SVN o Subclipse se solicitar nombre de usuario y contraseña y proporcionarlo y listo, se confirmará.

0

He actualizado mi eclipse y empecé a tener el mismo problema.

Hice todos los trucos, nada parece funcionar. Pero el viejo eclipse sigue funcionando.

lo tanto, me di cuenta de que alguien del equipo que había cambiado el caso de nombres de dominio, por lo que mi ID de usuario cambiado de:

DOMINIO \ nombre de usuario al dominio \ nombre de usuario

Así, después de eliminar \Users\<Your user name>\AppData\Roaming\Subversion, signo en el diálogo aparecer de nuevo y volver a la pista.

-1

Tuve el mismo problema cuando estaba cometiendo por primera vez una nueva rama de svn, que se debía a minúsculas utilizadas en la ruta de la URL cuando debería haber sido mayúsculas en el momento del pago. En la carpeta .svn del directorio de comprobación raíz, busque el archivo wc.db, ábralo en un editor de texto, realice un reemplazo global de la ruta URL incorrecta con la ruta URL correcta, guarde el archivo. Comprométase nuevamente, ya no tendrá ese problema.

4

Tengo el mismo problema. Estoy usando IntelliJ, y yo resuelto este problema haciendo lo siguiente: Archivo

  1. -> Configuración
  2. En "Control de versiones" lista de selección "subversión".
  3. En la ficha General, busque & Haga clic en "Borrar caché de autenticación".
  4. Hit Ok.
  5. Intente hacer el check-in de algunos cambios, y el Intellij le preguntará acerca de sus credenciales.

enter image description here

Parece que este problema ocurrió después de hacer svn switch --relocate comando en su rama desprotegido.

¡Disfrútalo!

+0

gracias por la pista, ¿qué versión de intellij? – shareef

+0

Versión Intellij: 14. –

0

En mi caso, la raíz del problema no estaba en la carcasa sino en el puerto svn cambiado.

solucionado esto con el traslado de la copia de trabajo:

svn switch --relocate https://svn.company.com/svn/path/branches/java8 https://svn.company.com:465/svn/path/branches/java8 
Cuestiones relacionadas