web-dev-qa-db-fra.com

Impossible de se connecter au repo avec TortoiseSVN

Cela fait quelques mois que je gère un projet utilisant le même référentiel TortoiseSVN jusqu'à présent, sans trop de problèmes.

Je dois ajouter une autre boîte au projet, mais il semble impossible pour TSVN de se connecter au référentiel. Voici ce que j'ai découvert ou essayé:

J'ai deux postes clients: le "vieux" et le "nouveau" ...

  1. Configurer et extraire un deuxième dossier sur la "vieille" boîte de dialogue fonctionne bien.
  2. La consultation du référentiel via Chrome/IE sur la "nouvelle" boîte fonctionne également très bien.
  3. Les navigateurs de ma "nouvelle" boîte n'utilisent pas de proxy (il en va de même pour la "vieille" boîte).
  4. J'exécute TSVN 1.7.4, version 22459 - 64 bits sur les deux boîtes

  5. Lorsque j'essaie de me connecter au référentiel à partir de la "nouvelle" zone à l'aide du navigateur de référentiel ou lors de l'extraction dans un nouveau dossier, le message d'erreur suivant s'affiche: 

    Impossible de se connecter à un référentiel à l'URL 'Https: // (adresse IP omise)/usvn/svn/(projet omis)' OPTIONS de 'https: // (adresse IP omise)/usvn/svn/(projet omis) ': ne pouvait pas se connecter au serveur (adresse IP omise)

  6. J'ai comparé tous les paramètres TSVN entre les "nouvelles" et les "anciennes" boîtes et elles semblent toutes correspondre

  7. Selon les utilisateurs du serveur, aucun certificat n'est utilisé
  8. Le pare-feu Windows sur le "nouveau" est en panne
  9. J'utilise à la fois les "anciens" et les "nouveaux" boîtiers du même réseau. Le "vieux" est connecté via WIFI mais le "nouveau" est en fil.

Je ne sais pas trop quoi vérifier, donc toute suggestion serait grandement appréciée.

Merci

svntortoisesvn
14
Jonas Rembratt

Vous devez déterminer s'il s'agit d'un problème avec TortoiseSVN, votre référentiel Subversion ou votre connexion réseau.

  • Tout d'abord, vérifiez votre URL. Je n'ai jamais utilisé SVN convivial , donc je ne sais pas ce que cela fait avec la configuration Apache httpd. Cependant, la configuration standard Apache pour plusieurs référentiels est généralement http://<server>/svn/<module> et non http://<server>/svn/usvn/<module>. Est-ce que ce répertoire /usvn/ est supposé être là?
    • À propos, comment Apache a-t-il été configuré? Est-ce que SVN convivial en fait aussi ou vous permet-il simplement de configurer les référentiels? Utilisez-vous Visual-SVN ou quelqu'un a-t-il configuré manuellement Apache httpd?
  • Si l'URL est correcte, essayez d'envoyer une requête ping à votre serveur Subversion. Pouvez-vous cingler à partir de votre machine Windows? Sinon, vous avez un problème de réseau. Pour une raison quelconque, l'adresse IP n'est même pas accessible depuis votre boîte client.
  • Essayez d’ouvrir un navigateur et de placer l’URL du référentiel Subversion dans la fenêtre. Cela devrait marcher. Si c'est le cas, le problème est probablement lié à TortoiseSVN. Téléchargez un client Subversion en ligne de commande et voyez si vous pouvez passer à la caisse avec cela.
  • Essayez d'utiliser la même URL sur une autre boîte. Pouvez-vous commander à partir de là? Si tel est le cas, cela indique un problème avec le réseau.
13
David W.

Essayez d'effacer les paramètres sous "Données sauvegardées" - reportez-vous à:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html

Cela a fonctionné pour moi avec Windows 7.

Eric

12
user2753722

J'ai constaté que le remplacement de la première partie de l'URL par des numéros d'adresse IP au lieu de mots fonctionnait pour moi.

Par exemple utiliser:

http://111.11.11.111/svn/Directory

au lieu de:

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

Je me débattais avec exactement le même problème. Mon ordinateur de travail a été remplacé et j'ai soudainement cessé de me connecter au serveur. Étrangement, au début, j'avais des erreurs qui ne me bloquaient que de commettre, comme par exemple: Commande: Valider Erreur: Valider avec validation (les détails suivent): Erreur: MKACTIVITÉ de '/ svn //! svn/act/c511b853-23b4-db4a-8991-0 bc689a63353 ': Erreur: Impossible d'analyser la ligne d'état de la réponse (http: // * .* *. com) Complété ! : 

Lorsque j'ai déménagé pour travailler dans une autre branche (le serveur SVN était accessible sans problèmes pour tous les utilisateurs des deux branches disposant de la sécurité appropriée), j'ai commencé à recevoir une erreur telle que:

Commande: extraction à partir de http: //.com/svn/fineos/ /trunk, révision HEAD, entièrement récursif, unités externes incluses Erreur: impossible de se connecter à un repository at URL Erreur: 'http: // * * . com/svn/fineos */* / trunk' Erreur: OPTIONS de Erreur : 'http: // * . com/svn/fineos */* / coffre': pourrait Erreur: ne pas se connecter au serveur (http: // * . com) Terminé! : 

Remarque: dans chaque cas, je pouvais accéder au référentiel via un navigateur et cela fonctionnait pour tout le monde. Il ne s'agissait donc évidemment pas d'un problème de réseau ou de référentiel. 

Ce qui a fonctionné pour moi a été de désinstaller le client Tortoise, puis de supprimer le dossier de cache Tortoise des dossiers locaux et itinérants sous C:\Utilisateurs \.utilisateur\Données d'application. En outre, j’ai renommé le nœud TortoiseSVN dans le registre Windows afin que l’ancienne configuration ne puisse pas être trouvée . Après la réinstallation, le client est connecté pour effectuer un repo magnifique. Je ne suis pas sûr que les deux étapes soient nécessaires, peut-être que changer de registre suffira, je vous laisse le soin de le confirmer. 

Toutes mes excuses pour une réponse longue, mais comme je n'ai pas vu de réponse à ce problème après avoir cherché Google pendant plus longtemps, j'ai pensé que cela pourrait être utile pour différents cas. 

2
Tomasz

SVN est sensible à la casse. Assurez-vous que vous l'orthographiez correctement. S'il a été renommé, vous pouvez déplacer le dossier de travail vers la nouvelle URL. Voir https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-relocate.html

1
as9876

Comme indiqué par David W. "Tout d’abord, vérifiez votre URL" - Notre entrée DNS a changé, cassant toutes les connexions svn repo. Se connecter sur ip au lieu de url comme Wes l'a déclaré travaillé - (maintenant nous devons réparer notre DNS) 

0
Tom A

Regardez aussi ceci: 

Issue: Après avoir appelé SVN sur la ligne de commande sur un serveur avec pare-feu, rien de visible ne se produit pendant 15 secondes. Le programme se ferme alors avec l'erreur suivante: 

svn: E170013: Impossible de se connecter à un référentiel à l'URL 'SVN.REPOSITORY.REDACTED'

svn: E730054: Erreur lors de l'exécution du contexte: une connexion existante a été fermée de force par l'hôte distant.

Enquête: Les recherches sur Internet concernant les erreurs susmentionnées n’ont révélé aucune information pertinente.

Le suivi du processus (procmon) a montré une tentative de connexion à un serveur Akamai (services de cloud computing) après l'établissement de la liaison SSL/TLS avec le serveur SVN. Le nom d'hôte du serveur n'était pas indiqué dans le suivi du processus. La recherche DNS inversée a indiqué a184-51-112-88.deploy.static.akamaitechnologies.com ou a184-51-112-80.deploy.static.akamaitechnologies.com comme nom d'hôte et l'adresse IP était 184.51.112.88 ou 184.51. 112.80 (2 entrées dans le cache DNS).

L'outil de capture de paquets (MMA) a montré une tentative de connexion au nom d'hôte ctldl.windowsupdate.com après la négociation SSL/TLS avec le serveur SVN.

L'API Windows Crypto tentait de se connecter à Windows Update pour récupérer les informations de révocation de certificat (CRL - liste de révocation de certificats). Le délai d'attente par défaut pour la récupération des listes de révocation de certificats est de 15 secondes. Le délai d’authentification sur le serveur est de 10 secondes; comme 15 est supérieur à 10, cela échoue. 

Résolution: Une recherche sur Internet a révélé ce qui suit: (voir l'image ci-dessous)

Solution 1: Réduisez le délai d'attente CRL. Stratégie de groupe -> Configuration ordinateur -> Paramètres Windows -> Paramètres de sécurité -> Stratégies de clé publique -> Paramètres de validation du chemin du certificat -> Récupération du réseau - voir l'illustration ci-dessous.

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

Solution 2: Pare-feu ouvert pour le trafic CRL

support.Microsoft.com/en-us/kb/2677070

Solution 3: indicateurs de ligne de commande SVN (non testés)

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout - solution de drapeau en ligne de commande svn alternative.

Informations complémentaires: Le débogage de ce problème a été particulièrement difficile. SVN 1.8 a désactivé la prise en charge de la bibliothèque Neon HTTP RA (accès au référentiel) au profit de la bibliothèque Serf qui a supprimé la journalisation du débogage du client. [1] De plus, le code d'erreur SVN renvoyé ne correspond pas à la chaîne indiquée dans svn_error_codes.h. [2] De plus, les codes d'erreur SVN ne peuvent pas être facilement mappés sur leur étiquette ENUM. Dans ce cas, le code d'erreur SVN E170013 est mappé sur SVN_ERR_RA_CANNOT_CREATE_SESSION.

  1. stackoverflow.com/questions/8416989/is-it-possible-tobget-svn-client-debug-output
  2. people.Apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c49979660a044e5248bb3a652768e5eb3105d6f28f
  3. code.google.com/archive/p/serf/issues/172

Suggestions de changements SVN: 

  1. Activer Verbosity sur la commande comme pour toutes les opérations

  2. Ajouter le nom d'erreur ENUM à stderr

  3. Ajouter un indicateur de configuration pour la journalisation du débogage de la bibliothèque Serf.

0
Cameron Sours