Contexte d'exécution d'erreur SVN: une connexion existante a été fermée de force par l'hôte distant
J'ai créé un référentiel SVN sur mon serveur de compilation Debian Wheezy après ce tutoriel } _.svn --version donne 1.6.17.
Malheureusement, je ne peux plus m'engager dans le repo depuis ma machine Windows 7; il échoue avec le message d'erreur suivant:
Transmitting file data .svn: E730054: Commit failed (details follow):
svn: E730054: Error running context: An existing connection was forcibly closed
by the remote Host.
J'ai eu cette erreur avec TortoiseSVN et le client en ligne de commande .
Voici le contenu de /var/log/Apache2/access.log sur le serveur au moment de la validation ayant échoué: access.log . Il n'y a pas d'entrée pour la même heure dans le journal des erreurs.
Je suis toujours en mesure de vérifier le contenu de la pension et svn info http://myurl/svn/myrepo fonctionne aussi très bien.
Le serveur Debian avec le référentiel s'exécute dans un VM sur Windows Server 2008 R2 (Hyper-V-Manager 6.1). La connexion de mon ordinateur Windows au serveur Windows est établie avec FortiClient 4.2.8.0307.
Après avoir rencontré cette erreur hier, j'ai purgé svn du serveur et réinstallé le référentiel. Cela a incité l'acceptation du référentiel à être validé pendant quelques heures jusqu'à ce qu'il échoue à nouveau avec la même erreur.
Les commandes actuellement validées fonctionnent à nouveau avec TortoiseSVN mais échouent avec le client en ligne de commande .
Que signifie E730054 et comment puis-je le réparer définitivement?
Entre temps, je suis passé à Jessie, mais la situation ne s’est pas améliorée. Les validations avec Tortoise ont cessé de fonctionner à nouveau, ce qui signifie qu’elle est suspendue pendant environ cinq minutes à l’action "Envoi de contenu", puis affiche l’erreur contenue dans le titre.
Les caisses fonctionnent toujours sans problème, cependant.
Apache2 -v:
Version du serveur: Apache/2.4.9 (Debian)
Version du serveur: 29 mars 2014 21:52:01
svn --version:
svn, version 1.8.8 (r1568071)
compilé le 1 avr. 2014, 03:41:42 sur i486-pc-Linux-GNU
Voici un thread qui traite de l'erreur, mais je ne pouvais pas en arriver à une solution à mon problème.
J'ai remarqué que le problème se produit lorsque je souhaite valider la modification second d'un fichier.
Mon correctif
Le problème a été résolu définitivement après l'utilisation de svnserve au lieu de Apache2. _ { Ce tutoriel } _ m'a aidé à le configurer.
Alors que je lisais le fil, il semble que certains problèmes dans l'implémentation de WEBDAV sur le site client plantaient le thread Apache. J'avais d'autres problèmes avec les référentiels pré-1.8 et j'ai résolu la plupart en déchargeant/rechargeant le référentiel entier dans un nouveau (utiliser " svnadmin upgrade " n'est pas suffisant!). Les dépôts pré-1.8 contiennent parfois des données "corrompues/obsolètes" dans des fichiers de révision qui sont ignorés par les clients. Il semble que cela pourrait causer le segfault.
Vous pouvez vider/recharger votre référentiel comme ceci:
svnadmin create newrepos
svnadmin dump oldrepos | svnadmin load newrepos
Notez que l'exécution d'un cycle de mise à jour/rechargement peut prendre beaucoup de temps (environ 1 Go/h + - 50%, principalement en fonction de la vitesse du disque).
Si vous avez une heure différente, merci de poster votre heure, je fais une recherche privée sur les performances du cycle de vidage/rechargement.
J'ai eu ce problème avec un seul fichier en essayant d'archiver plusieurs fichiers à l'aide de Tortoise SVN sur Windows 7 x64. Plusieurs tentatives de validation du fichier à l'aide de différentes versions de Tortoise SVN et de la version en ligne de commande de SVN ont échoué.
À l'époque, mon ordinateur portable utilisait la connexion Internet de mon domicile à mon fournisseur d'accès Internet. Plus tard, lorsque je suis allé au travail et que j'ai tenté de valider le fichier défaillant à partir du réseau de mon employeur, le fichier a été validé sans problème.
Je ne sais pas pourquoi c'était le cas, mais si vous rencontrez ce problème et trouvez votre chemin vers cette réponse via une requête d'un moteur de recherche, vous voudrez peut-être essayer à nouveau - en utilisant une connexion Internet différente. Bien que ce ne soit pas une solution au problème, il peut fournir une solution temporaire.
Je recevais cette erreur.
Erreur lors de l'exécution du contexte: une connexion existante a été fermée de force par la télécommande
J'ai résolu ce problème en basculant le proxy sur Cntlm et tout fonctionne parfaitement ..__ J'utilise la version TortoiseSVN 1.9.3
Je recevais cette erreur.
Erreur: une connexion existante a été fermée de force par la télécommande
J'utilise la version TortoiseSVN 1.11 . J'utilise un point de contrôle VPN, je redémarre simplement ma connexion VPN
J'ai eu la même erreur. Mon problème était avec l'antivirus Avast, quand j'ai mis l'URL du serveur svn dans les exclutions, le problème a été résolu.
J'ai rencontré ce problème après que notre serveur svn ait migré de LAN à Internet. Enfin, je résous ce problème en en changeant mon adresse IP .
Par exemple: de 192.168.0.60 à 192.168.0.71.
Version SVN: TortoiseSVN 1.9.7, version 27907 - 64 bits
Version du système d'exploitation: Windows 10, 1703
J'ai eu ce problème avec un grand commit (~ 500 fichiers, 50 Mo) sur un réseau de base. Cela fonctionnait lorsque je divisais le fichier en lots (par exemple, sélectionnez un fichier à la fois). Il semble qu’il ait particulièrement eu du mal avec 1 gros fichier répété pour plusieurs dossiers.