1. casa
  2. Domanda e risposta
  3. Impossibile connettersi al repository con TortoiseSVN

Impossibile connettersi al repository con TortoiseSVN

2012-01-24 23 views
14

Ho eseguito un progetto da alcuni mesi utilizzando lo stesso repository TortoiseSVN senza troppi problemi, fino ad ora.Impossibile connettersi al repository con TortoiseSVN

Ho bisogno di aggiungere un'altra casella al progetto ma sembra impossibile per TSVN connettersi al repository. Questa è la roba che ho scoperto o provato:

ho due scatole client: il "vecchio" e il "nuovo" ...

  1. Impostazione e check-out una seconda cartella sulla "vecchia" scatola funziona bene.
  2. Anche la ricerca sul repository tramite Chrome/IE nella casella "nuova" funziona correttamente.
  3. I browser nella mia casella "nuova" non usano un proxy (lo stesso vale per la "vecchia" casella).
  4. Sono in esecuzione TSVN 1.7.4, Build 22.459-64 bit su entrambe le caselle

  5. Quando tento di collegarmi al repo dalla casella "nuovo" utilizzando il browser repo o check-out in una nuova cartella ottengo questo messaggio di errore:

    Impossibile connettersi a un repository all'URL 'https: // (ip-indirizzo omesso)/usvn/svn/(progetto omesso)' OPZIONI di 'https: // (indirizzo-ip omesso)/usvn/svn/(progetto omesso) ': impossibile connettersi al server (indirizzo IP omesso)

  6. Ho confrontato tutte le impostazioni TSVN tra i "nuovi" e "vecchi" scatole e tutti sembrano corrispondere

  7. Secondo le persone che gestiscono il server non ci sono certificati in uso
  8. Il firewall di Windows sulla casella "nuovo" è giù
  9. I eseguo sia la "vecchia" che la "nuova" casella dalla stessa rete. Il "vecchio" è connesso via WIFI, mentre quello "nuovo" è collegato al filo.

Sono alla mia intelligenza fine su cosa controllare così ogni suggerimento sarebbe molto apprezzato.

Grazie

fonte

2012-01-24 Jonas Rembratt

+1

È possibile verificare in quale zona di rete è stato inserito Windows 7 (presumo che la tua casella sia un Win7), forse la tua zona di rete è causando il problema. – boto

+1

Cosa ne pensi degli strumenti della riga di comando svn? Questo almeno determinerebbe se si tratta di tartaruga o di sovversione in generale. – Barry

+0

boto: Non sono sicuro di come controllare la zona di rete in cui mi trovo (sì, sto eseguendo Win7 btw). Come è fatto e come posso vedere se la zona sta causando i problemi? –

risposta

12

È necessario determinare se questo è un problema con TortoiseSVN, il repository Subversion, o la connessione di rete.

  • Prima di tutto, controlla l'URL. Non ho mai usato User-Friendly SVN, quindi non so cosa faccia la configurazione di httpd di Apache. Tuttavia, la configurazione standard di Apache per più repository è solitamente http://<server>/svn/<module> e non http://<server>/svn/usvn/<module>. Supponiamo che la directory /usvn/ sia lì?
    • A proposito, come è stato configurato Apache? Anche SVN user-friendly lo fa o ti permette semplicemente di configurare i repository? Stai usando Visual-SVN o qualcuno ha configurato manualmente l'httpd di Apache?
  • Se l'URL è corretto, provare a eseguire il ping sul server Subversion. Puoi eseguire il ping dalla tua casella di Windows? In caso contrario, si è verificato un problema di rete. Per qualche motivo l'indirizzo IP non è raggiungibile dalla tua casella cliente.
  • Provare ad aprire un browser e inserire l'URL del repository Subversion nella finestra. Questo dovrebbe funzionare. Se lo fa, il problema è probabilmente con TortoiseSVN. Scarica un client Subversion dalla riga di comando e verifica se è possibile effettuare il checkout.
  • Prova a utilizzare lo stesso URL su un'altra casella. Puoi fare il checkout da lì? In tal caso, indica un problema con la rete.

fonte

2012-01-24 18:56:26

+0

Se si verifica un problema di rete, non impedisce a un normale browser Web di connettersi e navigare nel repository SVN. Potrebbe comunque essere un problema se il problema delle comunicazioni, supponendo che SVN usi un protocollo più complesso rispetto ai browser web. Ma non ho idea di cosa potrebbe essere. –

+2

@JonasRembratt - Quando si utilizza il protocollo http in Subversion, è puro 'http', quindi se una normale pagina web può passare attraverso la rete, dal server al client, così può Subversion via httpd Apache. È uno dei motivi per cui le persone usano http con Subversion. Sì, Subversion sta usando un modulo di WebDav su http, ma è tutto http. (In teoria, è possibile impostare un router in grado di leggere i pacchetti e filtrare i pacchetti http di WebDAV, ma non l'ho mai visto.) –

+0

Cosa succede se non riesco ad aprire l'URL del repository in un browser, anche se posso eseguire il ping del server trovato in quell'URL, posso collegarmi al repository dall'interno del mio posto di lavoro, il nostro amministratore insiste che l'URL dovrebbe essere raggiungibile una volta I ' m collegato alla nostra VPN (io sono, come evidenziato dalla possibilità di raggiungere altri siti interni) e nessuno dei miei colleghi ha problemi ad accedere al repository SVN mentre è a casa? Nonostante la tua guida passo-passo utile, non sono sicuro di cosa concludere da questi sintomi. –

2

Ho avuto esattamente lo stesso problema. Ho sostituito il mio portatile da lavoro e improvvisamente ho smesso di connettermi al server. Stranamente, inizialmente mi stavo errori solo mi blocco dal commettere, come: Comando: Commit errore: Commit fallito (dettagli seguire): Errore: MKACTIVITY di '/ svn//svn/act/c511b853-23b4-! db4a-8991-0bc689a63353 ': Errore: Impossibile analizzare la riga di stato della risposta (http: // *. * * .com) Completato! :

Quando mi sono trasferito a lavorare in un altro ramo (il server SVN era accessibile senza problemi per tutti su entrambi i rami, chi ha la sicurezza adeguata), ho iniziato a ricevere errore come:

Comando: Checkout da http: // .com/svn/FINEOS//tronco, HEAD revisione, completamente ricorsiva, esterni inclusi Errore: impossibile connettersi a un repository all'URL Errore: 'http: // * * .com/svn/fineos * /* /trunk' Errore: OPZIONI di errore: 'http: // * .com/svn/FINEOS * /* /trunk': potrebbe Errore: non connettersi al server (http: // * .com) Completato! :

Nota: in ciascun caso, potevo accedere al repository tramite browser e funzionava per tutti gli altri, quindi ovviamente non era un problema di rete o repository.

Ciò che ha funzionato per me è stato disinstallare il client Tortoise, quindi rimuovere la cartella cache Tortoise dalle cartelle Local e Roaming in C: \ Users \ utente \ AppData. Inoltre ho rinominato il nodo TortoiseSVN nel registro di Windows in modo da non trovare la vecchia configurazione. Quindi, dopo la reinstallazione, il client si è collegato al repository in modo bello. Non sono sicuro che siano necessari entrambi i passaggi, forse basterà cambiare il registro, lo lascerò a te per confermare.

Ci scusiamo per la lunga risposta, ma poiché non ho visto la risposta a questo problema dopo aver cercato su Google più a lungo, ho pensato che potrebbe essere utile per casi diversi.

fonte

2013-01-10 03:22:11 Tomasz

+0

Questo mi ha aiutato, è stato sufficiente eliminare la cache tramite il menu di scelta rapida => Impostazioni => Log Caching => Archivi cache => Elimina –

4

ho trovato che la sostituzione della prima parte dell'URL con i numeri di indirizzo IP invece di parole ha lavorato per me.

Ad esempio uso:

http://111.11.11.111/svn/Directory

anziché:

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

fonte

2015-08-20 20:42:00 Wes

0

guardare in questo così:

Problema: Dopo aver invocato SVN sulla riga di comando su un server con firewall, nulla di visibile accade per 15 secondi, quindi il programma si chiude con il seguente errore:

svn: E170013: Impossibile connettersi a un repository all'URL 'SVN.REPOSITORY.REDACTED'

svn: E730054: Errore durante l'esecuzione context: una connessione esistente forzatamente è stata chiusa dall'host remoto.

Inchiesta: La ricerca in Internet sugli errori di cui sopra non ha rivelato alcuna informazione pertinente.

Process Tracing (procmon) ha mostrato un tentativo di connessione a un server Akamai (servizi cloud) dopo l'handshake SSL/TLS al server SVN. Il nome host per il server non è stato mostrato in Traccia processo. La ricerca DNS inversa ha mostrato a184-51-112-88.deploy.static.akamaitechnologies.com o a184-51-112-80.deploy.static.akamaitechnologies.com come nome host e l'IP era 184.51.112.88 o 184.51. 112.80 (2 voci nella cache DNS).

Lo strumento di cattura pacchetti (MMA) ha mostrato un tentativo di connessione al nome host ctldl.windowsupdate.com dopo l'handshake SSL/TLS al server SVN.

L'API Crypto di Windows stava tentando di connettersi a Windows Update per recuperare le informazioni di revoca del certificato (CRL - elenco di revoche di certificati). Il timeout predefinito per il recupero CRL è di 15 secondi. Il timeout per l'autenticazione sul server è di 10 secondi; poiché 15 è maggiore di 10, ciò non riesce.

Risoluzione: ricerca su Internet ha scoperto quanto segue: (vedi anche foto in basso)

Soluzione 1: Criteri di gruppo Diminuzione CRL timeout -> Computer Config -> Impostazioni di Windows -> Impostazioni di protezione -> Criteri chiave pubblica -> Impostazioni di convalida del percorso del certificato -> Recupero della rete - vedi immagine sotto.

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

Soluzione 2: firewall aperto per il traffico CRL

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

Soluzione 3: SVN flag della riga di comando (non testati)

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - alternativo riga di comando svn bandiera soluzione.

Ulteriori informazioni: Il debug di questo problema è stato particolarmente difficile. SVN 1.8 supporto disabilitato per la libreria di Neon HTTP RA (accesso al repository) a favore della libreria Serf che rimuoveva la registrazione del debug del client. [1] Inoltre, il codice di errore SVN restituito non corrispondeva alla stringa fornita in svn_error_codes.h [2] Inoltre, i codici di errore SVN non possono essere mappati facilmente all'etichetta ENUM, in questo caso il codice di errore SVN E170013 si associa 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

suggerito SVN Modifiche:

  1. Abilita Verbosità sul comando come per tutte le operazioni

  2. Add errore di nome ENUM per stderr

  3. Aggiungi bandiera di configurazione per la registrazione di debug Serf Biblioteca.

fonte

2016-01-27 20:26:18

0

Come affermato dal David W. "Prima di tutto, controllare l'URL" - La nostra voce DNS cambiato rompendo tutte le connessioni svn repo. Connessione su IP invece di url come ha funzionato Wes - (ora dobbiamo correggere il nostro DNS)

fonte

2016-10-21 14:19:10

-1

Una volta ho affrontato lo stesso problema. Stavo cercando di fare svn checkout usando l'URL del repository composto da DOMAIN NAME. Ho provato a connettermi usando l'indirizzo IP al posto di DOMAIN NAME e sono stato in grado di prendere il checkout

fonte

2017-10-26 04:54:38

Problemi correlati

 Problemi correlati