2009-04-09 8 views
1

J'ai rencontré un problème étrange dans TorToiseSVN 1.6 dans une machine virtuelle: Je ne peux pas extraire les fichiers d'un système de contrôle de source en ligne. L'un des exemples que j'ai testé est:TortoiseSVN: Impossible de lire la ligne d'état dans la machine virtuelle

http://codesmith.googlecode.com/svn/trunk/ 

L'erreur que je suis arrivé était

options of *: could not read status line: connection was closed by http://codesmith.googlecode.com 

J'ai essayé de désactiver le pare-feu et antivirus sur la machine virtuelle, réglez la connexion au NAT pour la machine virtuelle, encore ça ne marche pas.

Des idées?

Répondre

0

Si vous ajoutez cette URL à votre navigateur, obtenez-vous les mêmes données dans la machine virtuelle et à l'extérieur?

+0

Oui. J'ai les mêmes données – Graviton

0

Probablement une question stupide, mais avez-vous configuré le proxy (si vous en avez besoin)? Il n'utilise pas les paramètres IE, mais se trouve sur la page TortoiseSVN -> Paramètres -> Réseau.

(désolé si vous avez pensé à cela, mais la question n'avez pas dit)

+0

Yup, j'ai pensé à ça, et j'ai essayé ... mais ça n'a pas marché. – Graviton

2

plus probable que ce soit un problème de proxy. Que se passe-t-il lorsque vous passez l'URL au protocole HTTPS?

https://codesmith.googlecode.com/svn/trunk/ 

Remarque - vous devez disposer d'un accès en écriture pour vous connecter via https. Si cela fonctionne via https, il s'agit d'un problème de proxy. Voir http://subversion.apache.org/faq.html#proxy

Pour diagnostiquer le problème, vous pouvez essayer de faire une caisse de ces URL:

http://svn.collab.net:81/repos/svn/trunk/ 
http://svn.apache.org/repos/asf/subversion/trunk/ 
https://svn.apache.org/repos/asf/subversion/trunk/ 

Collab.net écoute sur le port 81, ainsi que le port 80 pour aider les gens à contourner les procurations. De plus, leur serveur https ne nécessite pas d'authentification.

+0

Je ne vois pas de remplacement du port d'écoute du port 81 du proxy-bypass depuis le passage à ASF. –

1

J'ai rencontré ce problème sur mon serveur et il s'est avéré qu'il y avait des problèmes HTTP/HTTPS côté serveur. Est-il possible que votre FAI ou votre réseau utilise un proxy HTTP invisible?

Plus important encore, cela fonctionne-t-il en dehors de la machine virtuelle? Au moins, vous pouvez le réduire à un paramètre VM ou à votre connexion. Peut-être que vous pourriez aussi essayer SVN CHECKOUT à partir de la ligne de commande à l'intérieur de la machine virtuelle dans l'éventualité d'un problème Tortise.

Voici quelque chose que vous pouvez exécuter pour voir si un proxy caché est déconner avec votre connexion: http://netalyzr.icsi.berkeley.edu/

+0

J'aime ce programme .. c'est plutôt cool. – ShoeLace

0

Quel type de logiciel VM vous utilisez? Dans VMWare, je peux dire par expérience que certains types d'opérations réseau que j'ai essayé ont échoué sous NAT. La couche d'abstraction NAT peut casser des choses; Cependant, quand je suis passé à "Bridged", tout a bien fonctionné. Je vous suggère de définir votre NIC sur "Bridged", quel que soit le logiciel VM que vous utilisez. Voici la description du produit de VMWare:

Avec un réseau ponté, la machine virtuelle apparaît comme un ordinateur supplémentaire sur le même réseau Ethernet physique que l'hôte. La machine virtuelle peut alors utiliser de manière transparente tous les services des services disponibles sur le réseau auquel elle est raccordée, y compris les serveurs de fichiers, les imprimantes et les passerelles .De même, tout hôte physique ou toute autre machine virtuelle configurée avec un réseau ponté peut utiliser les ressources de cette machine virtuelle.

+0

Vous l'avez deviné: j'utilise VMWare – Graviton

+0

Le passage à Bridged a-t-il changé? –

Questions connexes