1. Inicio
  2. Pregunta y respuesta
  3. No se puede conectar al repositorio con TortoiseSVN

No se puede conectar al repositorio con TortoiseSVN

2012-01-24 24 views
14

He estado ejecutando un proyecto durante algunos meses usando el mismo repositorio de TortoiseSVN sin mucha molestia, hasta ahora.No se puede conectar al repositorio con TortoiseSVN

Necesito agregar otra caja al proyecto pero parece ser imposible que TSVN se conecte al repositorio. Este es el material que he descubierto o probado:

Tengo dos cajas de cliente: el "viejo" y el "nuevo" ... uno

  1. Configuración y la salida a una segunda carpeta en la caja "vieja" funciona bien.
  2. Navegar al repositorio a través de Chrome/IE en el cuadro "nuevo" también funciona bien.
  3. Los navegadores de mi casilla "nueva" no usan un proxy (lo mismo ocurre con la casilla "anterior").
  4. Me postulo TSVN 1.7.4, Build 22459 - 64 bits en ambas cajas

  5. Cuando intento conectar al repositorio de la "nueva" caja usando navegador de repositorios o el registro de salida a una nueva carpeta me sale esto mensaje de error:

    No se puede conectar a un repositorio en el URL 'https: // (dirección IP omitido)/USVN/sVN/(proyecto omite)' OPCIONES de 'https: // (dirección IP omite)/usvn/svn/(proyecto omitido) ': no ​​se pudo conectarse al servidor (dirección IP omitida)

  6. He comparado todas las configuraciones de TSVN entre los "nuevos" y "viejos" cajas y todos parecen coincidir

  7. De acuerdo con la gente que maneja el servidor no hay certificados en el uso
  8. El servidor de seguridad de Windows en la "nueva" caja se ha reducido
  9. I Estoy ejecutando el cuadro "viejo" y "nuevo" de la misma red. El "viejo" está conectado a través de WIFI sin embargo, mientras que el "nuevo" está conectado por cable.

Estoy en mi ingenio final sobre qué revisar, por lo que cualquier sugerencia sería muy apreciada.

Gracias

Fuente

2012-01-24 Jonas Rembratt

+1

Puede verificar en qué zona de red se metió Windows 7 (supongo que su casilla es un Win7), tal vez su zona de red sea causando el problema – boto

+1

¿Qué hay de usar las herramientas de línea de comando svn? Eso al menos determinaría si se trata de tortugas terrestres o subversión en general. – Barry

+0

boto: No estoy seguro de cómo verificar en qué zona de red estoy (sí, estoy ejecutando Win7 por cierto). ¿Cómo se hace eso y cómo puedo ver si la zona está causando los problemas? –

Respuesta

12

Es necesario determinar si se trata de un problema con TortoiseSVN, el depósito de la subversión, o la conexión de red.

  • Primero de todo, verifique su URL. Nunca utilicé User-Friendly SVN, así que no sé qué le hace a la configuración httpd de Apache. Sin embargo, la configuración estándar de Apache para múltiples repositorios suele ser http://<server>/svn/<module> y no http://<server>/svn/usvn/<module>. ¿Supongo que ese directorio /usvn/ está allí?
    • Por cierto, ¿cómo se configuró Apache? ¿El SVN fácil de usar lo hace también, o simplemente le permite configurar los repositorios? ¿Estás usando Visual-SVN o alguien configuró Apache httpd manualmente?
  • Si la URL es correcta, intente enviar un ping a su servidor de Subversion. ¿Puedes hacer ping desde tu caja de Windows? Si no, tienes un problema de red. Por alguna razón, esa dirección IP no se puede acceder desde su casilla de cliente.
  • Intente abrir un navegador y poner la URL del repositorio de Subversion en la ventana. Esto debería funcionar. Si lo hace, el problema probablemente sea con TortoiseSVN. Descargue un cliente de Subversion de la línea de comando y vea si puede pagar con eso.
  • Intente utilizar la misma URL en otro cuadro. ¿Puedes pagar desde allí? Si es así, apunta a un problema con la red.

Fuente

2012-01-24 18:56:26

+0

Si hay un problema de red, no impide que un navegador web normal se conecte y explore el repositorio SVN. Sin embargo, podría ser de algún tipo un problema de comunicación, suponiendo que SVN usa un protocolo más complejo que los navegadores web. Pero no tengo idea de lo que podría ser. –

+2

@JonasRembratt: cuando usa el protocolo http en Subversion, es puro 'http', de modo que si una página web normal puede pasar por la red, desde el servidor hasta el cliente, también lo puede hacer Subversion a través de Apache httpd. Esta es una de las razones por las cuales las personas usan http con Subversion. Sí, Subversion usa una forma de WebDav sobre http, pero es todo http. (En teoría, podría configurar un enrutador que pueda leer los paquetes y filtrar los paquetes http de WebDAV, pero nunca lo he visto hecho.) –

+0

¿Qué pasa si no puedo abrir la URL del repositorio en un navegador, aunque puedo hacer ping al servidor que se encuentra en esa URL, puedo conectarme al repositorio desde mi lugar de trabajo, nuestro administrador insiste en que la URL debe ser accesible una vez que m conectado a nuestra VPN (estoy, como lo demuestra al poder llegar a otros sitios internos) y ninguno de mis compañeros de trabajo tiene problemas para acceder al repositorio SVN mientras está en casa? A pesar de su útil guía paso a paso, no estoy seguro de qué concluir de estos síntomas. –

2

Estaba luchando con exactamente el mismo problema. Cambié mi computadora portátil y de repente dejé de conectarme al servidor. Curiosamente, en un principio que estaba recibiendo sólo errores bloqueo mí de haber cometido, como: Comando: Commit Error: la confirmación fallida (detalles a continuación): error: NKACTIVITY de '/ SVN//SVN/act/c511b853-23b4-! db4a-8991-0bc689a63353 ': Error: no se pudo analizar la línea de estado de la respuesta (http: // *. * * .com) ¡Completado! :

Cuando me mudé a trabajar en otra rama (el servidor SVN era accesible sin problemas para todo el mundo en ambas ramas, que tiene la seguridad adecuada), empecé a recibir error como:

Comando: Pedido de http: // .com/sVN/FINEOS//tronco, la cabeza revisión, totalmente recursivo, referencias externas incluidas Error: No se puede conectar a un repositorio en el URL de error: 'http: // * * .com/svn/fineos * /* /trunk' error: OPCIONES de error: 'http: // * .com/SVN/FINEOS * /* /trunk': ¿podría Error: No se puede conectar al servidor (http: // * .com) ¡Completado! :

Nota: En cada caso, podía acceder al repositorio a través del navegador y funcionaba para todos los demás, así que obviamente no era un problema de red o de repositorio.

Esto funcionó para mí para desinstalar el cliente Tortoise, luego quitar la carpeta Tortoise cache de las carpetas Local y Roaming en C: \ Users \ user \ AppData. Además, he cambiado el nombre del nodo TortoiseSVN en el registro de Windows, por lo que no se puede encontrar la configuración anterior. Luego, después de la reinstalación, el cliente se conectó maravillosamente al repositorio. No estoy seguro de si se requieren ambos pasos, tal vez cambiar el registro sea suficiente, se lo dejo a usted para confirmar.

Disculpas por la respuesta prolongada, pero como no he visto respuesta a este problema después de buscar en Google por más tiempo, pensé que podría ser útil para diferentes casos.

Fuente

2013-01-10 03:22:11 Tomasz

+0

Esto me ayudó, fue suficiente para eliminar la caché a través del menú contextual => Configuración => Almacenamiento en caché de registro => Repositorios almacenados en caché => Eliminar –

4

he encontrado que la sustitución de la primera parte de la dirección URL con números de direcciones IP en lugar de palabras trabajó para mí.

Por ejemplo uso:

http://111.11.11.111/svn/Directory

en lugar de:

http://www.url.com/svn/Directory

Fuente

2015-08-20 20:42:00 Wes

0

ver en esto, así:

Edición: Después de invocar SVN en la línea de comandos en el servidor cortafuegos, nada visible ocurre durante 15 segundos, a continuación, el programa se cierra con el siguiente error:

sVN: E170013: No se puede conectar a un repositorio en la URL 'SVN.REPOSITORY.REDACTED'

sVN: E730054: Error al ejecutar contexto: una conexión existente fue cerrada por el host remoto.

Investigación: La investigación en Internet sobre los errores anteriores no destapó ninguna información pertinente.

El seguimiento de proceso (procmon) mostró un intento de conexión a un servidor de Akamai (servicios en la nube) después de la comunicación SSL/TLS con el servidor SVN. El nombre de host para el servidor no se mostró en Trazado de procesos. La búsqueda DNS inversa mostró a184-51-112-88.deploy.static.akamaitechnologies.com o a184-51-112-80.deploy.static.akamaitechnologies.com como el nombre de host, y el IP era 184.51.112.88 o 184.51. 112.80 (2 entradas en el caché de DNS).

La herramienta de captura de paquetes (MCA) mostró un intento de conexión con el nombre de host ctldl.windowsupdate.com después del protocolo de enlace SSL/TLS al servidor SVN.

Windows Crypto API intentaba conectarse a Windows Update para recuperar información de revocación de certificados (CRL - lista de revocación de certificados). El tiempo de espera predeterminado para la recuperación de CRL es de 15 segundos. El tiempo de espera para la autenticación en el servidor es de 10 segundos; como 15 es mayor que 10, esto falla.

Resolución: investigación en Internet descubrió lo siguiente: (véase también el cuadro en la parte inferior)

Solución 1: Disminución CRL tiempo de espera de la directiva de grupo -> Informática Config -> Configuración de Windows -> Configuración de seguridad -> Directivas de claves públicas -> Configuración de validación de ruta de certificado -> Recuperación de red - ver imagen a continuación.

https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698

support.microsoft.com/en-us/kb/2625048

blogs.technet.com/b/exchange/archive/2010/05/14/3409948.aspx

Solución 2: abra el firewall para el tráfico CRL

support.microsoft.com/es-es/kb/2677070

Solución 3: indicadores de línea de comandos SVN (no probado)

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - línea de comandos svn alternativo solución de bandera.

Información adicional: La depuración de este problema fue particularmente difícil. SVN 1.8 deshabilitó el soporte para la biblioteca Neon HTTP RA (acceso al repositorio) a favor de la biblioteca Serf que eliminó el registro de depuración del cliente. [1] Además, el código de error SVN devuelto no coincide con la cadena indicada en svn_error_codes.h [2] Además, los códigos de error SVN no se pueden mapear fácilmente a su etiqueta ENUM, este caso el código de error SVN E170013 se asigna a SVN_ERR_RA_CANNOT_CREATE_SESSION.

  1. stackoverflow.com/questions/8416989/is-it-possible-to-get-svn-client-debug-output~~V~~3rd
  2. people.apache.org/~brane/svndocs/capi/svn__error__codes_8h.html # ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
  3. code.google.com/archive/p/serf/issues/172

sugerido SVN Cambios:

  1. Habilitar verbosidad en el comando como para todas las operaciones

  2. Agregar error de nombre ENUM a stderr

  3. agregar el indicador de configuración para Biblioteca Serf el registro de depuración.

Fuente

2016-01-27 20:26:18

0

Como señaló David W. "En primer lugar, comprobar su URL" - Nuestra entrada DNS cambiado romper todas las conexiones SVN repo. Conectarse en ip en lugar de url como dijo Wes funcionó - (ahora tenemos que arreglar nuestro dns)

Fuente

2016-10-21 14:19:10

-1

Una vez que tuve el mismo problema. Intenté tomar svn checkout utilizando el repositorio URL que consta de DOMAIN NAME. Intenté conectarme usando la dirección IP en lugar de DOMAIN NAME y pude tomar el pago

Fuente

2017-10-26 04:54:38

Cuestiones relacionadas

 Cuestiones relacionadas