La mise à jour à partir du référentiel svn renvoie l'erreur "Impossible de lire la taille du bloc"
Lors de la mise à jour à partir du référentiel Subversion à l'aide de tortoise svn client, l'erreur se présente de la manière suivante:
Could not read chunk size: An existing connection was forcibly closed by the remote Host.
Cela ne m'empêche pas de mettre à jour, il interrompt simplement le processus de mise à jour, de sorte que je dois répéter la mise à jour plusieurs fois avant qu'elle ne soit terminée.
Qu'est-ce qui peut causer un tel comportement et comment y remédier?
Je recevais le message "Impossible de lire la taille du bloc" des clients sur plusieurs ordinateurs.
La clé pour le déterminer était cette erreur dans le journal des erreurs Apache:
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Provider encountered an error while streaming a REPORT response. [500, #0]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Problem replaying revision [500, #24]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Can't open file '/usr/site/svnrep/impc/db/revs/16122': Too many open files [500, #24]
Le processus Apache qui gérait l'opération svn était à court de descripteurs de fichiers. Sur mon serveur Ubuntu, je l'ai corrigé en éditant /etc/security/limits.conf et en ajoutant ceci en bas:
* hard nofile 5000
* soft nofile 5000
Ce qui augmente la limite de descripteur de fichier de 1024 à 5 000. Ensuite, je me suis connecté sur un nouveau shell et j'ai confirmé que la limite avait été augmentée via ulimit -n. Puis redémarré Apache.
Je viens de recevoir l'erreur 'impossible de lire la taille du bloc' ET TROUVE UNE SOLUTION - au moins pour un scénario.
Tout d'abord, ma configuration ...
SERVEUR: CollabNet Subversion Edge Server 2.0.0-2190.74 (Binaires Subversion 1.6.17-2190.74) s'exécutant sur Windows Server 2003 32 bits.
CLIENT: TortoiseSVN 1.6.16, version 21511 - 32 bits (Sous-version 1.6.17) s'exécutant sous Windows XP Pro 32 bits avec SP3.
Étapes à suivre pour reproduire ...
J'ai eu cette erreur après avoir fait un clic droit en glissant un sous-dossier versionné dans un autre sous-dossier dans mon dossier de copie de travail local, puis en choisissant 'SVN Copiez le ou les éléments versus ici' (Il s'agit d'une commande de menu contextuel TortoiseSVN dans l'Explorateur Windows lorsque vous faites glisser des dossiers à droite). Le sous-dossier contenait un fichier texte codé en ANSI, MANIFEST.MF, que je crois ne pas avoir modifié (ma configuration Subversion n'inclut pas de type mime pour les fichiers .MF). J'ai par la suite commis le sous-dossier nouvellement copié. Plus tard, chaque fois que j’essayais de mettre à jour mes dossiers de copie de travail locale Subversion sur ce PC, j’obtenais l’erreur de taille de bloc.
Solution de contournement...
J'ai résolu ce problème en redémarrant mon service Subversion/Apache (ce qui en soi n'a pas aidé et n'a peut-être pas été nécessaire), puis suppression du sous-dossier récemment ajouté de mon dossier de copie de travail locale (il était déjà arrivé à la pension, alors je n'allais rien perdre), et ALORS effectuer une mise à jour, qui a réussi sans l'erreur de taille de bloc et a rouvert le sous-dossier que je viens de supprimer.
Dans mon cas, j'avais copié DEUX sous-dossiers versionnés de cette façon et je ne pouvais pas mettre à jour correctement la racine de mon dossier de copie de travail local tant que je n'avais pas effacé DEUX DE CES nouveaux sous-dossiers.
Suivre...
Je suppose qu’il s’agit d’un bogue du serveur Subversion et/ou du client TortoiseSVN, mais je n’ai pas les compétences de débogage pour prendre cette décision. Je vais rapporter mes découvertes dans le suivi des problèmes de TortoiseSVN et voir où elles vont.
Cela vient de m'arriver, et c'était pas un problème de serveur; ma copie de travail a été corrompue (par moi, incidemment).
Le problème et (certains autres) ont disparu après avoir désactivé l'antivirus côté client.
J'utilise un serveur Ubuntu avec Subversion 1.7.4 via Apache.
Pour nous, le problème était un dépassement de délai sur Apache. La mise à jour prenait environ 15 minutes, mais Apache a expiré au bout de 10 minutes, ce qui a amené notre serveur SVN à afficher l'erreur que vous voyez. La solution finale consistait à augmenter le délai d'attente pour Apache. Nous utilisons le serveur VisualSVN - pour des instructions détaillées sur la modification de ce paramètre, consultez la page suivante: http://adventuresindotnet.blogspot.com/2010/09/svn-trouble.html
Vérifiez le journal des erreurs Apache, il devrait y avoir une erreur enregistrée avec un numéro d'erreur. Ce numéro aidera à savoir pourquoi la connexion a été abandonnée.
S'il n'y a rien dans le journal des erreurs, vérifiez les paramètres de votre anti-virus/pare-feu: certains de ces outils abandonneront une connexion s'ils estiment que les données transférées sont dangereuses.
Je recevais ce même message d'erreur sur les mises à jour après avoir renommé un dossier et validé. J'ai créé un nouveau répertoire de travail et je n'ai pas reçu l'erreur. Je viens donc de déplacer mes modifications dans le nouveau répertoire de travail, de valider et de supprimer l’ancien répertoire.
Donc, cette erreur semblait être due à la corruption de mon répertoire local.
J'ai changé pour un serveur Ubuntu et nous avons eu la même erreur - avec plusieurs versions de PC client, de système d'exploitation et de client.
Après vous être assuré que les paramètres de limite de fichier et de délai d’exécution du test Apache étaient ceux suggérés.
(Voir http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/ )
J'ai finalement résolu le problème en utilisant le paquet Apache2-mpm-prefork plutôt que le paquet Apache2-mpm-worker.
Je comprends ça aussi. Notre serveur est Apache sous Windows. Mon client est connecté avec une latence élevée mais un peu élevée (200 ms.) L’autre partie du casse-tête est que je suis sous Windows Vista. Tourner autoscaling et rss semble améliorer la situation, mais ne la règle pas.
Il y a une autre cause ennuyeuse pour ce message d'erreur. Ce pourrait être votre routeur ou le micrologiciel de votre routeur.
J'avais récemment mis à niveau le micrologiciel de mon Linksys WRT110 de la version 1.0.02 à 1.0.07 et, par la suite, Subversion ne pouvait plus ajouter de nouveaux fichiers au référentiel. Il ne pouvait mettre à jour que les fichiers existants. Revenir à la version 1.0.02 a résolu le problème.
Sources:
- http://blog.wouldbetheologian.com/2008/12/warning-on-linksys-wrt110-firmware.html
- http://homecommunity.Cisco.com/t5/Wireless-Routers/Upgraded-WRT-110N-to-1-0-07-and-now-Subversion-won-t-work/td-p/321812
Fondamentalement, chaque fois que la connexion est interrompue brutalement, vous obtiendrez cette erreur. Peut-être une erreur de configuration sur Apache, comme beaucoup d’entre vous l’ont déclaré. Cela peut également être dû à un serveur lent ou à une connexion surchargée, ou à un routeur bon marché, comme dans mon cas.
Pour nous, la solution consistait à rétrograder le SVN client de 1,8 à 1,7 (client en ligne de commande fourni avec TortoiseSVN).
Cela a clairement plusieurs causes, mais pour moi cela a été corrigé en redémarrant mon serveur SVN (VisualSVNServer 2.5.1). Cela se produit fréquemment lors de l'extraction d'un référentiel complet sur un cliché récemment chargé.
VisualSVN 2.5.8: Si j'avais la même erreur, les étapes suivantes m'ont aidé à corriger cette erreur:
Sur le serveur:
- Supprimé sur le dossier problématique du serveur;
- Redémarrez le serveur VisualSVN.
Sur le poste de travail:
- Mettre à jour le dossier parent;
- Ajouter un dossier et des fichiers à nouveau;
- Ajouter à SVN;
- Commettre.